Patches welcome!

The only time that the CLI is using the nobody UID is when running package lifecycle scripts. In some cases, this will involve those scripts creating files, which will, if nothing else happens, be themselves owned by nobody. However, in almost all cases, the process won't have permissions to write as nobody (because privileges have been dropped to nobody and most global directories are owned by root with fewer permissions than are necessary for nobody to create files), so the situations in which this can cause problems are vanishingly few in number.

As such, I'm going to call that an issue with those packages and their lifecycle scripts, and close this as not an issue in the CLI. If somebody wants to make an attempt to close this hole opened by the lifecycle runner, we'd be happy to review patches, but really, this is something that should be addressed at the level of the individual packages with this issue. Thanks for your time!

@othiym23 you are very wrong, kind sir. Installing applications, utilities or servers globally will install them as user nobody:

$ sudo npm install -g typescript
[install log]
$ find /usr/lib -user nobody
[long list of files owned by nobody]

This is a serious issue, and should not be closed or ignored. The user nobody is not allowed to own any files, especially not files that might influence the running of, or even directly be services on the interwebs.

If we're talking about global installs with the user set as nobody, I'd like to reference #3849. This is still an issue in the latest version of npm.