-
Notifications
You must be signed in to change notification settings - Fork 3k
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
use groups for managing write-access to files #435
Conversation
Exactly want I wanted 👍 |
This won't fix permissions on mounted containers, right? Continuation: Since home is often mounted, shouldn't |
Correct, and rightly so - mounted volumes shouldn't have their permissions touched, right?
I don't think so. Since home is often mounted, it should already be mounted with the right permissions. It shouldn't be modified after mounting. |
They should not. Whenever we've accidentally done that, we've had bugs opened here with users saying their host permissions were changed. I think it's up to the user to match the host permission to whatever UID / GID they decide to use in the container. |
Thanks for the clarifications. |
base-notebook/README.md
Outdated
* `--group-add user-writable` - use this argument if you are also specifying | ||
a specific user id to launch the container (`-u 5000`), rather than launching the container as root and relying on NB_UID and NB_GID to set the user and group. | ||
|
||
It does not |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Leftover? Same with line below?
'r-rcurl=1.95*' && conda clean -tipsy | ||
'r-rcurl=1.95*' && \ | ||
conda clean -tipsy && \ | ||
fix-permissions $CONDA_DIR |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it possible to set the group sticky bit (+s) on the root conda directory so that group permissions are preserved across all installs without running this script each time?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Setting the sticky bit gets us almost there, and I did set it. Good call. New files have the right owners, but not the right permissions. For that, I think we need acls or the ability to set umask for subsequent RUN commands, but AUFS doesn't support ACLs and I don't see a way to set umask, so I think we're stuck. I'd love to be wrong, though.
Giving this a shot locally, mostly to better understand the changes and to see if we really need the |
# Have the Spawner override the Docker run command | ||
c.DockerSpawner.extra_create_kwargs.update({ | ||
'command': '/usr/local/bin/start-singleuser.sh' | ||
}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is start-singleuser no longer needed? If so, we should pull it from the other READMEs as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. start.sh
already dispatches to start-singleuser.sh
based on environment variables. Users don't need to know the difference.
- any files the user should be able to write should have group `user-permissions` with `g+rwX` - remove `chown` from start.sh because it is no longer needed - add `fix-permissions` script for setting the user-writable permissions on a path - user-permissions group as GID 10000 (is there a reason for it to have a different value?) - containers can set group with `--group-add user-writable` if they want to run with a different uid/gid (without -u root -e NB_UID -e NB_GID, which make this unnecessary)
ensures files have the right owner:group unfortunately, not enough to get group-writable permissions (need acl or umask for that), so we still need to run it after each install
use `users` instead
it’s handled internally
I've tested this locally and it works great. We should consider adding more doc about when / how it's useful vs the NB_USER, NB_UID, etc. env vars. Will merge this after the current round of images finishes building. (There's no way to communicate from one build to the next on docker cloud which git SHA to pull and build, so merging again in the meantime means we'll get a mix of code changes across the images for the same tag). |
The |
any files the user should be able to write should have group
user-permissions
withg+rwX
remove
chown
from start.sh because it is no longer neededadd
fix-permissions
script for setting the user-writable permissions on a pathusers group is GID 100
containers can set group with
--group-add users
if they want to run with a different uid/gid(without -u root -e NB_UID -e NB_GID, which make this unnecessary), for instance:
Questions:
users
group 100?closes #434
closes #395
I believe this resolves issues brought up in #188 without needing to consider the possible implications of running with gid=0