The setfacl command explicitly entered in the Dockerfile in the section e.g. CMD will not cause the ACLs to be set during the build; there are two effective methods to set the ACL on the container:
Starting the container, entering the console and issuing the setfacl … command, the ACL permissions granted in this way work, but when committing the container and running the committed image, these permissions are gone (commit does not keep them).
Defining a script in the Dockerfile in the ENTRYPOINT section, e.g. run.sh. In this script, we force the script to run, e.g. sh which grants permissions - this solution works as expected but has a major flaw; if the directory in which permissions are to be granted at startup has a lot of files (200,000) then permissions are granted 15 minutes. instead of 15 seconds, because that’s how long it should normally take.
You can be sure that your topic has been read. Though, I am quite sure no one feels comfortable enough with ACLs inside a container to respond. At least that’s why I didn’t respond so far.
What would be the benefits of using ACLs for file that are stored inside the image, especially if the extended permissions are not retained in the created image? A container is self-contained, as such the only processes that can access the container file system are running in the container itself.
@meyay Thank you for your answer, we have used ACL so far, but I do not insist on this solution if it is really such a problem. I would be grateful if you could suggest alternative solutions.
Sorry, I was on vacation and completely cut myself off.
What exactly are you interested in? In short, each client has a separate DB instance and application
in the chroot, on it the appropriate permissions are added for the appropriate one using setfacl.