Add ability to allow insecure writes

[kevin-bates]

Per a previous discussion, this change enables users to bypass the file permissions enforcement within secure_write(). This has become an issue when secure files reside on filesystems that automatically promote file permissions to o777 and prevents changes to those settings. In such cases, users can prevent enforcement by setting environment variable JUPYTER_ALLOW_INSECURE_WRITES to true (default = false).

I debated on the polarity of the env variable name. I liked JUPYTER_ENFORCE_SECURE_WRITES but felt having a variable that defaults to True was a bit odd. Also, I felt that users setting something to skip security by having to set it to True was a more explicit action.

In looking at testing this change, I couldn't find a way to get a file created such that it would exhibit the behavior of one of these filesystems. Since the change is trivial, I figured this could be a visual inspection kind of thing.

[MSeal]

+1 for overall. Do we need to do anything similar for the nt path? I suppose we could extend the env variable usage there if we encounter cases for it in the future. I added a suggestion for printing a warning so it's visible to admins that the check isn't being made.

[MSeal]

Thinking maybe we should print a warning?

Suggested change

	if 0o0600 != file_mode and not allow_insecure_writes:
	if allow_insecure_writes:
	warnings.warn("Insecure write mode enabled for `jupyter_core.paths.secure_write` function")
	elif 0o0600 != file_mode:

[kevin-bates]

I was thinking about this (although I would have just logged the warning in the 'insecure' case, rather than unconditionally) but felt it would occur (essentially) at every kernel startup request on applicable systems and could be lost in the general log messages (particularly when DEBUG is enabled, which I often recommend). However, I see that warnings.warn() just logs once, but again, that could be "lost in the noise".

I do like the idea of informing the admin that this setting is in effect, more or less confirming their intention. I wonder if placing this warning message in JupyterApp.initialize(), or equivalent, might be more useful. That way it's logged before any "violation" takes place. We'd probably want a bold "WARNING" and not rely on the logging level indicator for something like this. The downside would be for those apps that use jupyter_core but bypass JupyterApp.

This message would be something like...
WARNING: Insecure writes have been enabled via environment variable 'JUPYTER_ALLOW_INSECURE_WRITES'! If this is not intended, remove the variable or set its value to 'False'.

[MSeal]

I'd be fine with that. Having the warning just-in-time is fine too imo. Just-in-time also catches when an application sets the environment after it loads before it runs something but that's probably not an edge case worth solving for on purpose. Up to you how you want to address it, i'd be good with merging with what's been described.

[kevin-bates]

Thanks @MSeal. I went with messaging on two fronts, at app startup and first violation. Because not all users of secure_write may derive from JupyterApp, I felt the JIT warning was also necessary. Here's what a user starting Notebook will see if they've enabled the env variable:

$ jupyter notebook
WARNING: Insecure writes have been enabled via environment variable 'JUPYTER_ALLOW_INSECURE_WRITES'! If this is not intended, remove the variable or set its value to 'False'.
[I 09:08:32.470 NotebookApp] Serving notebooks from local directory: /Users/kbates/repos/oss/jupyter/jupyter_core
[I 09:08:32.470 NotebookApp] The Jupyter Notebook is running at:
[I 09:08:32.470 NotebookApp] http://localhost:8888/?token=5eb58a5d49303ac15a8b36d318d25a75edab360202072f0a
[I 09:08:32.470 NotebookApp]  or http://127.0.0.1:8888/?token=5eb58a5d49303ac15a8b36d318d25a75edab360202072f0a
[I 09:08:32.470 NotebookApp] Use Control-C to stop this server and shut down all kernels (twice to skip confirmation).
[I 09:08:32.470 NotebookApp] Welcome to Project Jupyter! Explore the various tools available and their corresponding documentation. If you are interested in contributing to the platform, please visit the communityresources section at https://jupyter.org/community.html.
[C 09:08:32.478 NotebookApp] 

I found I needed a custom format method so that the warning's location isn't prefixed to the message and I found that the output would also include the actual statement (which seems strange).

Since the same warning message is logged only once, applications deriving from JupyterApp won't see the JIT message, while applications not derived from JupyterApp will see it on first occurrence - and not after. If we wanted this to be more "in your face" we can switch to using logger.warn instead - then all violations will be posted.

[MSeal]

LGTM!

[MSeal]

Do you want me to get a release going?

[kevin-bates]

That would be awesome - thank you.

[MSeal]

Released in 4.6.2