[jkercher]

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.

[marcosdumay]

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.

[bobbylarrybobby]

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?

[suprjami]

I think parent comment means "cp badthing ls" and leave it latent for someone to run. Maybe $PATH has CWD first for convenience?

[Dylan16807]

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).

[mathfailure]

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.

[mdnahas]

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.

[zahlman]

Might I ask exactly what the typo was?

[lanyard-textile]

Elaborate?? "." has been at the end of my PATH for like 20 years.

[mlrtime]

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

[lanyard-textile]

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.

[ahepp]

Just to save the trouble of writing './'?

[lanyard-textile]

Yes??? :)

I'm not the crazy one here! That's a whole two characters on the same side of the keyboard...

[oneeyedpigeon]

How often do you find yourself running executables from the current directory? Is this a daily thing?

[lanyard-textile]

Gamedev! I could run some crazy cmake command to build and run, or I could just bin/build.

[piekvorst]

For my workflow, yes

I don’t think it’s a severe security vulnerability. The same thing can happen with $home/bin.

[ahepp]

I 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.

[zelphirkalt]

Why does this go wrong and in what situation?

[necovek]

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.

[mathfailure]

> 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.

[necovek]

Yeah, there are ways to reduce the impact (as a sibling comment mentioned, typos or commands missing on a system could still be used to trick the operator), but I was mostly explaining the attack vector in case it is present in the PATH.

[drivers99]

Then it's a little bit of a stretch but they could put a script with the name of a common typo similar to commonly run commands there. Maybe "ls-l" without the space in case they miss the space. Yeah, that's a stretch. I went looking for better sources.

> The current directory ( . ) is not in PATH by default, for security reasons. This prevents accidentally running unintended programs in your current directory.

-- POSIX Shell scripting from scratch, By Sultan Zavrak (states it in general terms. They also use ls as an example though, which shouldn't be affected if you have "." at the end.)

Practical UNIX and Internet Security has an example of "." (or having a null entry in the PATH, which also indicates the current directory; I didn't know that![0]) at the beginning, which is obviously a bad idea, but he (Simson Garfinkel) makes a good point:

> More generally, you should never have a path that is writable by other users.

Ah yes, finally, he covers a situation where you have a directory at the end of your path, that is writable by others ("." would count) and having a trojan named "mroe" (for "more") waiting patiently for the superuser to mess up.

He even goes so far to say that root should run commands with full paths, such as /sbin/chown and not just chown. I've never gone that far, except I can see the benefit of doing that in scripts.

So anyway, besides the typo example, there's also a kind of shadowing: let's say you expect a command to fail because the program is not installed. Or maybe you try to run a command you think is installed but it's not. You might even have a command or way of working that tries various commands until one works. If you have a path that someone can write to (including ".") then instead of failing, it will run something unintended, if they have shadowed that command in that directory.

[0] to quote the bash man page: A zero-length (null) directory name in the value of PATH indicates the current directory. A null directory name may appear as two adjacent colons, or as an initial or trailing colon.

[renewiltord]

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?

[mathfailure]

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.

[pwg]

Appending is much better than prefixing, but having "." in the path, anywhere, can still open you up to running mistyped commands (arguably a much less common possibility, but still a possibility).

I.e., you have "." as the very last item in your path. You are in /tmp/ (so a directory other uses can write files to). You mean to type "ls -l something" to look for "something" files. But instead, you just miss the space, and type "ls-l something*", and some other nefarious user has left a /tmp/ls-l binary behind just waiting to be run. It could package up your ~/.ssh folder and ship it off to "nefarious" user, and then do a proper "ls -l" so that you may not even notice the typo.

And, if you happen to be root when you are in /tmp and mistype ls-l, and if the ls-l binary checks to see if it is being run as root, it could then do even worse. For example, it could leave behind an suid to root bash or sh executable in 'nefarious user's' home dir, so that 'nefarious' can now become root at some point later and proceed to actually 'own' the system.

[renewiltord]

Right, 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.

[Kiboneu]

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.

[Kiboneu]

lol. What a beautiful footgun — for such a tiny optimization.