I’m not bothered by it because I have a workaround, but
I’d like to know the underlying reason.
Is this the way manjaro is currently designed?
Not sure when this happened, and maybe the thread title isn’t the proper way to put it, but after a couple months or so of suddenly having to type out full paths to my home/.local/bin I’m tired of it. Hoping someone knows what this is.
This is from KDE Konsole, zsh or bash no difference.
However, there is an alternative way of escalating privileges that does work with local paths: run0
I just tried running a script I keep in my local ~/bin/ directory:
~ songwords
What is the name of the song?:
What is the name of the artist or band performing the song?:
Song:
Artist:
Is this correct? n
Incorrect input - script will exit in 5 seconds
~ sudo songwords
sudo: songwords: command not found
~ run0 songwords
What is the name of the song?:
What is the name of the artist or band performing the song?:
Song:
Artist:
Is this correct? n
Incorrect input - script will exit in 5 seconds
If the /etc/sudoers file has secure_path enabled, then you will not be able to run scripts located in directories outside the ones listed in secure_path.
secure_path is enabled in my /etc/sudoers file - I think it is enabled by default on Manjaro.
Here are the relevant lines in my /etc/sudoers file:
## Use a hard-coded PATH instead of the user's to find commands.
## This also helps prevent poorly written scripts from running
## arbitrary commands under sudo.
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/bin"
Especially having in mind the default path in manjaro is to prefer a local home path before the system ones (which is a stupid idea and a BAD security practice). Imagine the damage if a malicious script in your local bin is called “sudo” or “pacman”. It would run BEFORE the actual sudo, you would happily give the (pwned) sudo your root password and here is your privilege escalation. There is a simple one line fix for that but somehow @Yochanan did not agree with me.
So that secure path is kind of protection against that.
This has been discussed years ago - whether or not the user’s local bin folder should be in the path - and we recently discussed it as someone thought it was a good idea to remove /etc/profiles.d/home-local-bin.sh from the filesystem package.
The default order in the path is /usr/local/bin;/usr/bin which would make /usr/local/bin equally usable for a pawn script.
Having a path an order of precedence like ~/.local/bin:/usr/local/bin:/usr/bin is simply an extension of other order of precedence rules - e.g. for configuration files or lib files.
That goes for /usr/local/bin as well.
There is valid usecases for overriding scripts in /usr/bin or /usr/local/bin which makes ~/.local/bin very useful.
Just in the last six months, I’ve typed that command (sudo ~/bin3/myGrub.sh) 176 times.
In fact, it’s been running for over 12 years.
I’ll take it as a new specification for me.
Writing in /usr already requires root rights. Writing in /home does not. If there was indeed no difference, permissions wouldn’t exist. We know how this goes with security and stability, some of us remember windows 98.
I also wonder how often is indeed needed to create custom scripts overwriting stuff like sudo, cat, run0, pacman. And how many of the people that do this are home users of manjaro (and not gentoo for example, or normal arch).
P.s. oh wait, i remember someone asking in the forum how to remove cat, ls and other coreutils from his system. So there is at least one
Besides ~/.local/bin simply being a reasonable place to put your own scripts…
I currently also use it to fix subdl and smplayer that both have upstream bugs … placing my own versions there to usurp the existing ones is a tad less intrusive than, for example, replacing the package-provided executables in /usr/bin.
User-specific executable files may be stored in $HOME/.local/bin. Distributions should ensure this directory shows up in the UNIX $PATH environment variable, at an appropriate place.
No, because a wrong (“inappropriate”) implementation of the other specified dirs/variables does not lead so easily to privilege escalation.
And it is not a nuclear physics to fix too.
case ":${PATH}:" in
*:"$HOME/.local/bin":*) ;;
*) export PATH="$PATH:$HOME/.local/bin" ;;
esac
instead of
case ":${PATH}:" in
*:"$HOME/.local/bin":*) ;;
*) export PATH="$HOME/.local/bin:$PATH" ;;
esac
Actually, it was fixed a couple months ago and the fix was reverted with the last update.
That very much says that ~/.local/binshould exist, and should be in PATH.
Even beyond that we have systemd expecting it too. It definitely shouldnt be gone.
The rest of your comment does not do away with it but changes the way its implemented.
The previous ‘fix’ was to remove /etc/profile.d/home-local-bin.sh from filesystem package entirely - removing ~/.local/bin from PATH, which as shown, would be antithetical to the specifications, and would certainly break lots of peoples workflows - which is why it was reverted.
But you arent talking about removing it … just putting it at the end. Which would break my nifty overwrites, but would still make ~/.local/bin functional.
For whatever its worth debian/ubuntu and others add this directory to the beginning of PATH as it already is.
I personally think that at the point some malicious code can be installed and ran … it kinda does not matter if it is taking the place of an existing executable or not. It could be named anything and be just as malicious. Or if an actor can write to your $HOME then they will have multiple other avenues to accomplish such overwrites … including alias in your .bashrc and so on.
But I also dont care enough or claim to be an expert enough to proclaim it should be one way or another. Aside from the already established concept of its existence and inclusion in PATH.
I actually tried that (exploiting alias). Seems like, at least for bash, and at least for sudo, there is some kind of internal protection. You cannot alias sudo. Besides, scripts running in background do not follow the aliases in .bashrc and co. Seems like some of the bash developers thought about security.
alias may not allow it … but its not some internal safety check by bash or sudo.
Instead overwrite it using a function;
~/.bashrc
[...]
sudo () {
echo hello
}
[...]
$ source .bashrc
$ sudo
hello
$
Again, I wasnt setting out to prove much here, alias was a first thought.
This is just thought #2 … and it works fine. I’m sure theres a hundred others that dont involve ~/.local/bin being in (front or back of) PATH.
And actually … since you mentioned it and I opened bashrc … I do have sudo aliased without issue. Its aliased to 'sudo ’ (an extra space), due to a quirk that helps other aliases using sudo run more reliably.
