Skip to content
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

Merged
merged 4 commits into from
Aug 26, 2017

Conversation

minrk
Copy link
Member

@minrk minrk commented Aug 11, 2017

  • 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

  • users 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:

     docker run -u 501:501 --group-add users -it jupyter/base-notebook
    

Questions:

  • is there a reason we need a dedicated high-gid group for this? Or can we leave it as the default 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

@wakonp
Copy link

wakonp commented Aug 11, 2017

Exactly want I wanted 👍

@akhmerov
Copy link
Member

akhmerov commented Aug 15, 2017

This won't fix permissions on mounted containers, right?

Continuation: Since home is often mounted, shouldn't fix_permissions still be run on startup on home?

@minrk
Copy link
Member Author

minrk commented Aug 16, 2017

This won't fix permissions on mounted containers, right?

Correct, and rightly so - mounted volumes shouldn't have their permissions touched, right?

Since home is often mounted, shouldn't fix_permissions still be run on startup on home?

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.

@parente
Copy link
Member

parente commented Aug 16, 2017

Correct, and rightly so - mounted volumes shouldn't have their permissions touched, right?

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.

@akhmerov
Copy link
Member

Thanks for the clarifications.

* `--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
Copy link
Member

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
Copy link
Member

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?

Copy link
Member Author

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.

@parente
Copy link
Member

parente commented Aug 22, 2017

Giving this a shot locally, mostly to better understand the changes and to see if we really need the NB_USER and such overrides going forward. I did immediately see that docker run on v 17.xCE does not recognize -g. Is that flag a typo in the description of the PR or am I missing something?

# Have the Spawner override the Docker run command
c.DockerSpawner.extra_create_kwargs.update({
'command': '/usr/local/bin/start-singleuser.sh'
})
Copy link
Member

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.

Copy link
Member Author

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
@parente
Copy link
Member

parente commented Aug 26, 2017

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).

@minrk
Copy link
Member Author

minrk commented Aug 26, 2017

The -g was just a typo. It should have been -u uid[:gid].

@parente parente merged commit c879782 into jupyter:master Aug 26, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

start.sh performance issue
4 participants