NPM and sudo

[Dan Peddle]

I've dug around a bit, and there seems to be some different opinions about whether or not to use npm with sudo - mainly to do with global installs, creating symlinks etc.

For example, when setting up a new personal machine (mac or linux), I would chown /usr/local to belong to my login user, hence not having to sudo global npm actions. If I were to use the superuser later for whatever reason, then that trumps any lower permissions, and so on.

What's the canonical opinion about this? Would this advice differ from development environments to production ones..?

Dan

[Christopher Rust]

What's the issue with root owning the globally installed npm modules? Permissions should be set by npm so that whatever utilities are still be executable by your user.

Maybe it's common but I've never heard of anyone chowning /usr/local to their main user. It seems especially dangerous if there's applications in there that expect to run under their own special user account.

Personally, I wouldn't do that in Dev or Production. The way I see it global installs from npm are used to install things to the PATH, like applications, not necessarily to retrieve source code for development, like regular installs. In the same way you need sudo to install from your system repositories, you need sudo to install from npm globally.

I assume this is mainly because, correct me if I'm wrong, Linux is a multi user system by nature. You don't want just anyone or any user account to have access to edit the paths where shared user applications get installed.

Forcing everything to be owned by your user may prevent you from having to type sudo but I'm not sure I see any other advantages.

--
Job board: http://jobs.nodejs.org/
New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md
Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
---
You received this message because you are subscribed to the Google Groups "nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+un...@googlegroups.com.
To post to this group, send email to nod...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/CACTUpAfubXUsoHH46LJR39r9xbERqGe5W_Gsbz43yq%3D3As8bEQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Sam Roberts]

On Sun, Jan 4, 2015 at 9:51 AM, Christopher Rust <cru...@gmail.com> wrote:
> Maybe it's common but I've never heard of anyone chowning /usr/local to
> their main user.

Let me introduce you to Isaac Schlueter:
http://foohack.com/2010/08/intro-to-npm/

And almost everyone I know.

If you are setting up a production machine, probably best to install
node as root, and if absolutely necessary to do any npm global
installs (should be rare), run the global installs as root, or with
sudo, and use --unsafe-perm so that scripts run with sufficient privs
to succeed, and so that the ~/.npm/ cache is writeable.

Yes, that means you need to trust the code you install globally as
root... and yes, you ***better*** trust things you install globally as
root on a production box!

> It seems especially dangerous if there's applications in
> there that expect to run under their own special user account.

And do so using suid/sgid bits? Not likely. Technically possible, but
that's not how systems generally run daemons as particular users.

> Forcing everything to be owned by your user may prevent you from having to
> type sudo but I'm not sure I see any other advantages.

Some advantages:

- a number of npm install scripts will fail when run with sudo,
because they are run with privs of nobody, and can't write to the fs,
the symptoms of which can be subtle and maddening to debug. I speak
from sad experience, here.
- avoiding your .npm cache from containing a mix of root and user-owned packages

[Aria Stewart]

> On Jan 5, 2015, at 3:45 PM, Sam Roberts <s...@strongloop.com> wrote:
>
> On Sun, Jan 4, 2015 at 9:51 AM, Christopher Rust <cru...@gmail.com> wrote:
>> Maybe it's common but I've never heard of anyone chowning /usr/local to
>> their main user.
>
> Let me introduce you to Isaac Schlueter:
> http://foohack.com/2010/08/intro-to-npm/
>
> And almost everyone I know.

I think there's a strong argument for chowning /usr/local to a user's ownership on a single-user machine, and to leave it as root (or staff-owned) on a shared one.

> If you are setting up a production machine, probably best to install
> node as root, and if absolutely necessary to do any npm global
> installs (should be rare), run the global installs as root, or with
> sudo, and use --unsafe-perm so that scripts run with sufficient privs
> to succeed, and so that the ~/.npm/ cache is writeable.

As a heads up: --unsafe-perm is the default when run as root. You don't need to specify it.

>> Forcing everything to be owned by your user may prevent you from having to
>> type sudo but I'm not sure I see any other advantages.
>
> Some advantages:
>
> - a number of npm install scripts will fail when run with sudo,
> because they are run with privs of nobody, and can't write to the fs,
> the symptoms of which can be subtle and maddening to debug. I speak
> from sad experience, here.

Yeah, this is painful. Beware!

> - avoiding your .npm cache from containing a mix of root and user-owned packages

This was a bug in earlier npm; upgrade to the latest and this won't happen.

Aria

[Sam Roberts]

On Mon, Jan 5, 2015 at 12:54 PM, Aria Stewart <ared...@nbtsc.org> wrote:
>> If you are setting up a production machine, probably best to install
>> node as root, and if absolutely necessary to do any npm global
>> installs (should be rare), run the global installs as root, or with
>> sudo, and use --unsafe-perm so that scripts run with sufficient privs
>> to succeed, and so that the ~/.npm/ cache is writeable.
>
> As a heads up: --unsafe-perm is the default when run as root. You don't need to specify it.

Good to know. I guess I can understand the rationale... and now I
know why I occaisonally get reports that running as root and running
using sudo fail differently. :-(

>> - avoiding your .npm cache from containing a mix of root and user-owned packages
>
> This was a bug in earlier npm; upgrade to the latest and this won't happen.

By latest, you mean fixed in npm2?

npm2 is pretty much mandatory on Windows, the pain of not using it is
greater than any risk, but I've been a bit reluctant to recommend
Linux user's upgrade to it in production. Maybe unreasonably
reluctant. But once 0.12 is out the world will start using it, and any
issues will get shaken out pretty fast.

Sam

[Christopher Rust]

Thanks for the information.

> - a number of npm install scripts will fail when run with sudo,
> because they are run with privs of nobody, and can't write to the fs,
> the symptoms of which can be subtle and maddening to debug. I speak
> from sad experience, here.

Can you comment anymore on this?

What does privileges of nobody mean? Why couldn't a command run as root write to the fs?

Sorry for the ignorance.

--
Job board: http://jobs.nodejs.org/
New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md
Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
---
You received this message because you are subscribed to the Google Groups "nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+un...@googlegroups.com.
To post to this group, send email to nod...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/CACmrRmTq-ug5F8zCoA_xvOp1qFVgAjZmM43nna_vM%3DgUeOZbeg%40mail.gmail.com.

[Aria Stewart]

> On Jan 5, 2015, at 5:22 PM, Sam Roberts <s...@strongloop.com> wrote:
>
> On Mon, Jan 5, 2015 at 12:54 PM, Aria Stewart <ared...@nbtsc.org> wrote:
>>> If you are setting up a production machine, probably best to install
>>> node as root, and if absolutely necessary to do any npm global
>>> installs (should be rare), run the global installs as root, or with
>>> sudo, and use --unsafe-perm so that scripts run with sufficient privs
>>> to succeed, and so that the ~/.npm/ cache is writeable.
>>
>> As a heads up: --unsafe-perm is the default when run as root. You don't need to specify it.
>
> Good to know. I guess I can understand the rationale... and now I
> know why I occaisonally get reports that running as root and running
> using sudo fail differently. :-(
>

Nope! sudo's as root too. Should all be the same. If you're not using npm@2, though, that's where I'd put my blame.

>>> - avoiding your .npm cache from containing a mix of root and user-owned packages
>>
>> This was a bug in earlier npm; upgrade to the latest and this won't happen.
>
> By latest, you mean fixed in npm2?
>
> npm2 is pretty much mandatory on Windows, the pain of not using it is
> greater than any risk, but I've been a bit reluctant to recommend
> Linux user's upgrade to it in production. Maybe unreasonably
> reluctant. But once 0.12 is out the world will start using it, and any
> issues will get shaken out pretty fast.

There are a bunch of race conditions in npm@1.4. They're subtle, tricky, and some of them are silent. Random failures? Files just not written? missing bits and bobs? Blame race conditions. I'd quite frankly put some fear in of using npm@1. npm@2 is a way safer bet.

Aria

[Aria Stewart]

On Jan 5, 2015, at 5:57 PM, Christopher Rust <cru...@gmail.com> wrote:

Thanks for the information.

> - a number of npm install scripts will fail when run with sudo,
> because they are run with privs of nobody, and can't write to the fs,
> the symptoms of which can be subtle and maddening to debug. I speak
> from sad experience, here.

Can you comment anymore on this?

What does privileges of nobody mean? Why couldn't a command run as root write to the fs?

npm drops privileges when running scripts. If those scripts make broad assumptions, things break.

Aria

[Sam Roberts]

On Mon, Jan 5, 2015 at 2:57 PM, Christopher Rust <cru...@gmail.com> wrote:
> Thanks for the information.
>
>> - a number of npm install scripts will fail when run with sudo,
>> because they are run with privs of nobody, and can't write to the fs,
>> the symptoms of which can be subtle and maddening to debug. I speak
>> from sad experience, here.
>
> Can you comment anymore on this?
>
> What does privileges of nobody mean? Why couldn't a command run as root
> write to the fs?

Nobody is a user who is not you, or root, and has not much privilege.
Certainly not enough to write into a /usr/local/... that is owned by
root. Remember, you used sudo because even your own user could not
write into /usr/local? Well, neither can the user "nobody", by design.

A simple npm install script, say "node-gyp rebuild || 0", is run as
the user nobody if npm was originally run as root with sudo. So it can
not write anything to the fs.

This is because any package.json could put into its install script "rm
-rf /", which would suck for someone who installed it if they ran npm
install as root using sudo. So, dropping privs to nobody solves this.
Of course, it doesn't help you at all if they put "rm -rf $HOME"...
but I digress.

The price of priv dropping is high, it means that package scripts
don't work for any module that is globally installed. Or ***any*** of
the dependencies of such a module. Which could be any module, pretty
much.

So, don't use install-time package scripts.

But, other people might use them. And maybe you won't know... until
you finally track down a mysterious bug, and realize that its because
the install or post-install script didn't actually work.

Cheers,
Sam

[Sam Roberts]

On Mon, Jan 5, 2015 at 2:43 PM, Aria Stewart <ared...@nbtsc.org> wrote:
>
>> On Jan 5, 2015, at 5:22 PM, Sam Roberts <s...@strongloop.com> wrote:
>>
>> On Mon, Jan 5, 2015 at 12:54 PM, Aria Stewart <ared...@nbtsc.org> wrote:
>>>> If you are setting up a production machine, probably best to install
>>>> node as root, and if absolutely necessary to do any npm global
>>>> installs (should be rare), run the global installs as root, or with
>>>> sudo, and use --unsafe-perm so that scripts run with sufficient privs
>>>> to succeed, and so that the ~/.npm/ cache is writeable.
>>>
>>> As a heads up: --unsafe-perm is the default when run as root. You don't need to specify it.
>>
>> Good to know. I guess I can understand the rationale... and now I
>> know why I occaisonally get reports that running as root and running
>> using sudo fail differently. :-(
> Nope! sudo's as root too. Should all be the same. If you're not using npm@2, though, that's where I'd put my blame.

Sorry, Aria, I'm not following you anymore.

You just wrote that --unsafe-perm is is the default when running as root.

It is NOT the default when running "sudo npm" (sudoing to root).

Therefore, running as root and running "sudo root" can behave differently.

Am I missing something?

[Aria Stewart]

> On 5 Jan 2015, at 23:27, Sam Roberts <s...@strongloop.com> wrote:
>
> Sorry, Aria, I'm not following you anymore.
>
> You just wrote that --unsafe-perm is is the default when running as root.
>
> It is NOT the default when running "sudo npm" (sudoing to root).
>
> Therefore, running as root and running "sudo root" can behave differently.
>
> Am I missing something?

No, that'd be me, sorry. It defaults to false for unsafe-perm as root. Sorry about that.

unsafe-perm is true for non-root by default, and vice versa.

So to set it to unsafe-perm for root would be to allow scripts to run as root, and "just work", where "just work" can include "hose my whole system".

Sorry about that!

Aria

[zladuric]

Technically, sudo npm isn't running as root. It's running as that user, but with root privileges. Do files get written as the user to, say, /usr/local.

Personally, from my humble 18 year linux experience, I would not install just anything into /usr/local, only battle tested stuff. Sometimes you have to, but avoid it on production if possible. Most anything you would usually use on a internet site, production box, should use it's own user, not root, and have majority of deps be either local (like your code or npm modules) or very well tested (like pm2).

[Aria Stewart]

> On Jan 6, 2015, at 3:57 AM, zladuric <zlad...@gmail.com> wrote:
>
> Technically, sudo npm isn't running as root. It's running as that user, but with root privileges. Do files get written as the user to, say, /usr/local.

I'm not sure there's a meaningful difference there. Either way, it's uid 0.

Aria

[Zlatko Đurić]

Yeah, the difference can be mostly ignored. Effectively, without -E flag to sudo, `sudo npm` would be just the same as if called from a root shell, environment doesn't get transfered like that.