-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Privileged docker images write files with inappropriate UIDs and GIDs #66
Comments
As an interim approach, I wonder if we could have a |
Possibly helpful article: https://vsupalov.com/docker-shared-permissions/` |
Yes, I think one could start up the mysqld image, running bash instead of whatever it's entrypoint is, and smash the files in question. Note that this shows why privileged docker containers are a horrible security threat! But I have no idea why these containers are run as privileged. Maybe they don't need to be, in which case the techniques in the above article would address the issue. |
I think, technically, only the worker needs to be run as privileged. It stems from the way singularity runs inside of docker, and most of the planutils packages are singularity images. But maybe this whole thing is moot if the MySQL container doesn't need to run as privileged. We found it convenient for all to be built on top of the same planutils-parent image, but creating the container doesn't need that escalated mode. Just running the planners (so only the workers). |
OK, with some help from StackOverflow this seems to be the recipe:
|
There are documents in the docker hub page about the mysql image that suggest it can be run in userspace, and one might want to ensure that the user-id in the container and the user invoking |
For reference, https://medium.com/redbubble/running-a-docker-container-as-a-non-root-user-7d2e00f8ee15 It took longer than I would like to admit, but I've finally managed to make it work over [here]. I'll open another (small) PR for it, once the current one goes through. Caveat: I wasn't able to figure out how to nuke the folder from within the container...that virtual mount is a powerful thing :P. Plus, the MySQL image is extremely stripped down. Not much available from the inside. |
I should have emphasized that I was able to delete the contents of that folder -- |
Not if we need the folder removed :P. What got me hung up for so long was that it’s not the permissions in the container that creates the db_data folder ownership, but rather the user space of the docker (or docker compose), which is typically root. Key is to create the directory first (user space), and then fire things up. You’ll need to find a way to wipe what’s there, but the new PR that’s opened ( #68 ) should spin things up (with |
If one mounts a host machine directory (e.g.,
server/db_data
) into a docker container running privileged in a rootless docker, then one can get files created that the owning user on the host machine does not own, and cannot delete, causing failures to start:That file's UID and GID are both 328532966 on the host machine, so I have to bug a sysadmin to delete them before I can restart, or do a really complicated hokey-pokey where I docker exec bash in the MySQL DB container and do the job there....
Is there some way I could set the
MYSQL_USER
inenv
to avoid this?The text was updated successfully, but these errors were encountered: