Carl, I also had issues posting to the group on Friday night/Saturday morning.
I fear that we are talking past one another. I will try to be much clearer in my responses. If we cannot resolve this via email, I am willing to host a Skype session to talk through. Anyone on the list would be welcome to join. We agree on the "why" running on anything other than root is a good idea. I think we are discussing more about the "how to" run on some other ID. What I did not understand is "why" you handle it the way you do. Also, I would like to pre-apologize if I am talking down to you or anyone. You say, "We don't know the UID until runtime." I am not sure why you would want to know what that UID is at all or ever. The /etc/passwd convers the username to the UID. The nice thing about Tomcat/TomEE, it runs as the user that calls it. As long as java is available, it will start. You propose that in order to create that specific user and start TomEE as that user, you do the following: 1) Alter the /etc/passwd file to have group write access 2) Altering catalina.sh to add the user to /etc/passwd 3) Setting the ownership of the /usr/local/tomee to UID:root 4) Setting permissions of all files and directories in /usr/local/tomee to g=u 5) "USER" 1001 in the Dockerfile 6) CMD ["catalina.sh", "run"] in the Dockerfile. This line will start TomEE as the UID set in #5 7) When Catalina.sh is run, it adds the user to the passwd file, then starts TomEE as UID 1001, in your case with the user tomee. I propose the following to create the user and start TomEE 1) useradd in the Dockerfile to create the user tomee in the /etc/passwd file 2) "USER tomee" in the Dockerfile 3) CMD ["catalina.sh", "run"] in the Dockerfile. This line will start TomEE as the UID set in #2 To be clear, I have no pony in this race other than finding the best way. If I am wrong, I have learned something valuable! If you would like you can see my Dockerfiles in tomitribe/docker-tomee, grab them and run some tests. Some hosting providers have specific requirements for running as a user other than root. Maybe, that is why Tomcat has decided to sidestep the whole discussion and run as root out of the box and let the user sort it out. Maybe, we should do the same. While it is a security issue, it becomes a default standard issue to try to fix. Have a nice day!! Rod. On 11/25/19, 4:01 PM, "Carl Mosca" <[email protected]> wrote: Hi Rod, I am seeing some of my messages bouncing back - perhaps they are too long so I apologize if this was already sent: I am not sure if you're asking "why" I think it's a good idea to run as an arbitrary UID or the "why" behind what's going on with doing so...I try to touch on all of it: We don't know the UID until runtime (but we do know that user will be in the root group). While I acknowledge that this seems clumsy at first, and I am far from a security expert, it does seem more secure to me if one cannot predict the runtime UID as Red Hat describes in the OCP docs. If one is always using the *same known* UID, I think the attack surface changes a bit. If there is a need or desire in any given container/application to make that unknown UID be a particular user I see two options: One, we can change an already existing user which can be messy/hard/impossible depending file/directory ownership needs that are required for some applications and order of installation operations. (When I say impossible I am thinking of a particular situation I bumped into which is admittedly a corner case and most likely not applicable here.) The second option is just wait to create the user at runtime. Given the permission changes, we can modify /etc/passwd as described, which results in the creation of the user. In addition, other "chmod g=u" operations are what allows us to take ownership of other files/directories if/as needed at runtime. There are certainly situations where the username simply does not matter and the arbitrary UID in root group is used then there's no need to add a user. HTH, Carl
