Configurable notebook permissions (file based)

[chris246]

For our multi-user setup of Jupyter (using JupyterHub on Debian Linux) we need to grant writing access to the owning group of a Notebook.
Per default, Jupyter creates Notebooks that are writeable only for the creating user (and readable for the group and everyone else).

A possible approach would be to allow the configuration of Unix permissions in the configuration file of Jupyter and evaluate and set those permissions in notebook/notebook/services/contents/fileio.py
Although, this would not cover users using Windows.

What is your opinion on this matter in general and the approach?

[takluyver]

Maybe this is something that would make more sense to do in Jupyterhub?

[minrk]

I think setting default permissions needs to be done at the FileContentsManager level. I'm happy for an option / different defaults in JupyterHub if that makes sense, but I think the option needs to be exposed somewhere in the single-user code. Unless setting umask for the process is enough, in which case JupyterHub can do it at the Spawner level.

[dclong]

I came across issues (with the .ipynb_checkpoints directories) when trying to setup file permissions using umask. Please refer to this issue.

[chris246]

In our case, the checkpoint directories are also a problem.
Maybe - as @minrk suggested - this could be implemented inside the FileContentsManager, if fileio is the wrong place.

I can take a closer look for a fix in October, if that is ok.

[dclong]

@chris246
Great! Looking forward to a fix!

[dclong]

I quickly checked the code and found the following piece of code which might be the root cause.

./services/contents/filecheckpoints.py:            ensure_dir_exists(cp_dir)

The function ensure_dir_exists is in ipython_genutils/path.py. It has a parameter mode with default value 0o755. Passing the right mode to ensure_dir_exists might resolve the issue.

[chris246]

Sorry for the delay.

Afaik umask had to be set for every user, which is not feasible in our environment.

I took a closer look on implementing the change in FileContentsManager.

My approach:

1. Introduce new properties with default values and expose them to the notebook configuration file:
   • FileContentsManager.file_permission = 0o755
   • FileContentsManager.dir_permission = 0o755
2. Modify FileContentsManager.save() and implement setting the specified permissions for every model['type']

Open Questions:

1. Python 2 uses a different permission notation, 0755. Are there best practices for handling such issues?
2. Permission setting using this approach will not work under Windows. Is that a problem?

FileContentsManager source

[takluyver]

There's a fix coming in notebook 5.3 to respect umask correctly (#3002). Notebook 5.3 should be released any day now.

Once that's out, it sounds to me like the best solution is to add support for setting umask in the relevant Jupyterhub spawners. Adding config to the notebook for default file permissions feels like we're reinventing something that the operating system already provides.

[chris246]

Ok.

Just for clarification/as summary: Notebook 5.3 will respect the current umask setting.
According to #2858, this already works for notebooks, but not for directories (especially .ipynb_checkpoints).
This is fixed by #3002.

Users can modify the notebook configuration to set the desired umask using Python.
Maybe this possibility can be explained in the Docs.

Setting the umask inside the configuration is an easy solution, that we can also apply in our environment.

Thank you for your support!

[takluyver]

That sounds about right. JupyterHub might also gain an official setting to control the umask when starting individual notebook servers (changing it in the notebook config file is a clever trick rather than something we designed).

[asuchit]

Jupyterhub does not start the server till home directory is not set at 757 ?

I need to change the home directory /home/{user} permissions from 755 to 757.

Is there any other way to fix this issue ?

[RRosio]

Hello, I'm closing this issue as it has had no updates in the last 365 days. Please feel free to reopen this issue if it still needs to be addressed. Thank you!