Comment by jkercher
20 days ago
Tangentially related. Don't ever put "." in your PATH. I used to do this to avoid typing the "./" to execute something in my current directory. BAD IDEA. It can turn a typo into a fork bomb. I took down a production server trying to save typing two characters.
It used to be very common to "own" a unix system by adding a `ls` binary in some folder and waiting for an administrator to run it.
Why would this own a server? ls lists itself, but listing itself shouldn't cause it to run again? Where's the infinite loop that brings the server down?
I think parent comment means "cp badthing ls" and leave it latent for someone to run. Maybe $PATH has CWD first for convenience?
They're not talking about the same scenario. Owning isn't denial of service. And they didn't say the `ls` lists things (though it probably will do that at the end).
I like to follow my own convention where I name files with shell scripts with an extension: .sh for POSIX-compatible scripts, .bash for scripts with bashisms or .zsh for scripts with zshisms.
If I ever wanted to achieve what you initially wanted to achieve - I could use something like
alias -s sh=sh
alias -s bash=bash
alias -s zsh=zsh
Just like I do bind .txt and .conf to 'less', .pdf to 'qpdf', .json to 'ijq', video formats to 'mpv' and so on.
Related: My grad school had a shared bin/ directory with common local tools. Of course, that directory was after /bin and /usr/bin in the PATH so that no one could override “ls” or “more”. So… one grad student added scripts with names that matched common typos: “sl” and “mroe”!
Sure enough, they got run. The scripts didn’t take over your account. They ran “ls” and “more”. They may have also logged your username in a file so he could lord it over you.
Might I ask exactly what the typo was?
Elaborate?? "." has been at the end of my PATH for like 20 years.
I could drop a shell script that does something like
echo "lanyard2 ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/lanyard2 ; ls
if you ran ls in my dir, you would give me sudoers access
If you put . at the end of PATH, isn't it checked last? I would need to have a missing ls installation.
Still viable though for something like rg... Maybe you run it before you install it for the first time on a new machine.
Just to save the trouble of writing './'?
Yes??? :)
I'm not the crazy one here! That's a whole two characters on the same side of the keyboard...
4 replies →
Why does this go wrong and in what situation?
Somebody mentioned it elsewhere, but it is a security risk: if you end up in a directory that's not under your control, and you do a "ls", it might execute "./ls" instead of /usr/bin/ls, and that can be doing anything, including piping your ~/.ssh/id_* to a remote server.
This can also happen by downloading something off the internet (git clone, or tar xz foo.tar.gz), or on a multi-user system (eg. someone can put any of these common commands into /tmp/ and wait for you to drop into it and try a "ls" there) — if you have any untrusted content anywhere, you are exposed.
> if you end up in a directory that's not under your control, and you do a "ls", it might execute "./ls" instead of /usr/bin/ls,
Not if if you APPEND the dot path to the PATH env: the system traverses the dirs specified in the PATH env from left to right and stops at first match. Your system's ls binary is in the dir that's to the left of your '.' dir.
2 replies →
Presumably a script that aliases a common thing or something and then it uses the same. E.g. someone adds ./sed that has some default params and calls sed. You’re intended to call it with ~/not-in-path/defaulted/sed and it is supposed to then call sed but instead calls itself if it’s earlier in the path hierarchy.
Might even be as simple as “detect if I’m running gnu sed or bsd sed and use the appropriate one”. Obviously you can not have this problem by being smart about other things but defense in depth right?
Not if if you APPEND the dot path to the PATH env: the system traverses the dirs specified in the PATH env from left to right and stops at first match. Your system's sed binary is in the dir that's to the left of your '.' dir.
2 replies →
A trip down the recursion hole. Also, scripts will inherit the relative path so they will have different absolute paths from each other. Seems easier to just type ./ so it's kinda funny in a "UNIX haters handbook" kind of way, but it's not even a fault in linux's command interface in that case. We've all been there.
Oh, that's without even going into the security risks and loss of portability.
lol. What a beautiful footgun — for such a tiny optimization.