4 ms·
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
by jkercher 8mo 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.
- Kiboneu 8mo agolol. What a beautiful footgun — for such a tiny optimization.
- lanyard-textile 8mo agoElaborate?? "." has been at the end of my PATH for like 20 years.
- ahepp 8mo agoJust to save the trouble of writing './'?
- lanyard-textile 8mo agoYes??? :) I'm not the crazy one here! That's a whole two characters on the same side of the keyboard...
- oneeyedpigeon 8mo agoHow often do you find yourself running executables from the current directory? Is this a daily thing?
- piekvorst 8mo agoFor my workflow, yes I don’t think it’s a severe security vulnerability. The same thing can happen with $home/bin.
- ahepp 8mo agoI think it's substantially riskier. At the very least, it means you are trusting any directory you cd into, rather than just trusting your $home/bin. Stuff that would not typically raise eyebrows has been made risky. You might cd into less privileged user's $home, or some web service's data directory, and suddenly you've given whoever had access to those users, access to your user. Maybe you could argue "well, I just won't cd outside of my $home", but the sheer unexpectedness of the behavior seems deeply undesirable to me.
- lanyard-textile 8mo agoGamedev! I could run some crazy cmake command to build and run, or I could just bin/build.
- mlrtime 8mo agoI 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
- lanyard-textile 8mo agoIf 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.
- zelphirkalt 8mo agoWhy does this go wrong and in what situation?
- Kiboneu 8mo agoA 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.
- renewiltord 8mo agoPresumably 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?
- mathfailure 8mo agoNot 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.
- renewiltord 8mo agoRight, that's one way to be half-smart about it. But you have to make sure that's the final thing you append to the path. An easy mistake to make is temporal. You add `.` to the path, and time passes, someone appends `/opt/bin` to the path, and time passes, someone writes `~/not-in-path/defaulted/busybox` that references `/opt/bin/busybox` as just `busybox` and tests it by running `~/not-in-path/defaulted/busybox` while being in `~` and it works so they leave it alone, then you go `cd ~/not-in-path/defaulted/` and run it and die. "I don't understand. I very specifically appended `.` at the end!" Of course you can stick a comment "#the following should always be at the end of the file" or whatever or say "we should always make sure to reference binaries by their full path, so always write out `/opt/bin/busybox` rather than just `busybox`" and stuff like that. With enough system you can make this unlikely.
- mathfailure 8mo agoI 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.
- zahlman 8mo agoMight I ask exactly what the typo was?
- marcosdumay 8mo agoIt 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.
- bobbylarrybobby 8mo agoWhy 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?
- suprjami 8mo agoI think parent comment means "cp badthing ls" and leave it latent for someone to run. Maybe $PATH has CWD first for convenience?
- Dylan16807 8mo agoThey'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).
- mdnahas 8mo agoRelated: 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.