Consider security of environment

[rkdarst]

JupyterHub makes a big deal about not allowing users to alter their own environment for their single-user server:
https://jupyterhub.readthedocs.io/en/latest/reference/websecurity.html

First, I was wondering if I was missing something, because altering their own single-user would only serve HTML to themselves, so should be safe, right? (Besides, users of the same cluster could be considered "semi-trusted" but we should at least be aware of the issues)

But, assuming we need to be worried about this, we can evaluate the different spawners. For example, while setting up SlurmSpawner, I saw that by default, if --export=VAR,... is used, it will simulate a login shell and get the user's clean environment (as in, like what you might get on a fresh login) and then use that as the base, which directly allows people to do arbitrary env vars. Many spawners probably start a shell, which could evaluate config files. Basically, there are many possibilities here.

I had some mitigations:

• Use full path of jupyterhub-singleuser and start Python with -E -s

We can't fix every spawner and every cluster's own environment. We can provide documentation for batchsystem maintainers to consider when writing their scripts. We could make some tests for others to know if they are affected.

What do you think?

[rkdarst]

Let's face it, right now almost every spawner evaluates shell startup files for users. SlurmSpawner did, even with --keepvars, because srun was not used which was required for this to take effect. Limiting environment then broke users' software that was being run. I don't have time to go through it all now, but let's just say that properly fixing things will require a detailed, spawner-specific analysis and will likely impact some users.

#97 at least now mentions that this is a currently unsolved problem and we can't guarantee security.

[rkdarst]

Also if environment variables are used to authenticate as an admin, they are usually going to be passed to the user as well. req_keepvars can stop that but it's unwieldy to use. Consider this, too.