3 ms·

Out of interest I followed the link to "installed in my home directory under ~/.local/bin", because I use the same method for "global" user installation of some

by tomxor 9y ago

Out of interest I followed the link to "installed in my home directory under ~/.local/bin", because I use the same method for "global" user installation of some npm packages and arbitrary little tools I put together... anyway I discovered this: > export PATH=$HOME/.local/bin:$PATH > Notice I put it in the front of the list. This is because I want my home directory programs to override system programs with the same name. For what other reason would I install a program with the same name if not to override the system program? I've always made a point of doing the exact opposite of this when adding to /etc/profile, with the reasoning of: why the hell would I want to allow any user script to be able to override system commands without root permission? Have I gotten this all wrong? I admit I am no expert on bins and paths and security, but isn't the above a potential security issue?

johnmaguire2013 9y ago
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 worry about other users placing binaries at `/root/.local/bin`.
- 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.
CJefferson 9y ago
This is often called being "on the wrong side of the airtight hatch". If a program can write to ~/.local/bin, it can write to ~/.profile and change your path anyway, or set aliases.
- tomxor 9y ago
  > If a program can write to ~/.local/bin, it can write to ~/.profile and change your path anyway You're absolutely right, but in the case that a program can write to ~/.local/bin but no where else, it is a concern. What I'm really talking about is when a package manager is using that directory and potentially untrustworthy packages can put whatever they want in ~/.local/bin but not ~
avhon1 9y ago
> allow any user script to be able to override system commands Other users could only override system commands if they can write files to your ~/.local/bin As /u/CJefferson pointed out, if a user has permission to write files to your ~/.local/bin, they can probably also write to your ~/.profile and ~/.bash_profile. As long as you control the contents of your home directory, modifying your $PATH to include ~/.local/bin is safe.

by tomxor 9y ago

johnmaguire2013 9y ago

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 worry about other users placing binaries at `/root/.local/bin`.

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.

CJefferson 9y ago

This is often called being "on the wrong side of the airtight hatch". If a program can write to ~/.local/bin, it can write to ~/.profile and change your path anyway, or set aliases.

tomxor 9y ago
> If a program can write to ~/.local/bin, it can write to ~/.profile and change your path anyway You're absolutely right, but in the case that a program can write to ~/.local/bin but no where else, it is a concern. What I'm really talking about is when a package manager is using that directory and potentially untrustworthy packages can put whatever they want in ~/.local/bin but not ~

avhon1 9y ago

> allow any user script to be able to override system commands Other users could only override system commands if they can write files to your ~/.local/bin As /u/CJefferson pointed out, if a user has permission to write files to your ~/.local/bin, they can probably also write to your ~/.profile and ~/.bash_profile. As long as you control the contents of your home directory, modifying your $PATH to include ~/.local/bin is safe.