3 ms·

Well, if you're running as `root`, then `$HOME` will point to `/root`. Assuming `/root` is set to only allow `root:root` to write to it, then you don't need to

• tomxor 9y ago
  sorry i meant root as in /etc/profile not the root user, this is inherited by all user sessions. I will update my comment to clarify this. But actually this also applies to your own user .profile or .bashrc or whatever shell you have. I suppose more specifically I am talking about using a package manager which essentially gives write permission to ~/.local for individual package maintainers and that you might not be able to trust (this applies to NPM in particular). As an example: For the users's own session, I don't want apt linking to some nefarious bin if for instance I have a npm package whom's authors credentials are hacked at some point, inserting an extra ~/.local/bin/apt binary when it's updated. For this scenario the overriding $PATH method will cause apt to run the nefarious binary rather than the system one. [edit] I think I might have answered my own question through example... it's a security problem when pointing a package manager at the bin where individual package maintainers can publish at any time and be hacked at any time. But I suppose in the authors example, he is using it for his own scripts ONLY, often specifically for the purpose of subverting system package versions, in which case overriding is as safe as the user is.
  • gkya 9y ago
    I don't think the global profile should be setting user paths. Just add the usual /bin /sbin and /usr variants of these. That way an unknowing user would be less likely to run into the issue you're describing.