

What's wrong with having '.' in your $PATH? - invisiblefunnel
http://www.faqs.org/faqs/unix-faq/faq/part2/section-13.html

======
paulitex
This is more of a tip than a warning. This answer was clearly written when
*nix systems were largely multi-user systems. The security reasoning doesn't
hold at all on personal computers - in fact I'm going to add "." to my PATH
for sure now, hadn't ever considered it. (I'm pretty sure I don't leave
malicious executables "lying around" my mac, and if I somehow did that'd be my
own dumb fault).

~~~
ssp
A lot of the classic Unix security advice is pretty outdated. For example the
idea that someone getting "root" access is worse than someone gaining "ssp"
access. Everything interesting is already readable and writable by ssp. The
only new thing root can do is destroy stuff that can pretty easily be
recreated.

The root account is still useful to prevent ssp from accidentally screwing
things up, but as a security measure it's pointless in many cases.

~~~
caf
ssp oughtn't be able to make arbitrary alterations to the kernel, though. As
such it's a lot harder to hide your tracks as ssp than it is as root.

------
bluesmoon
Having . in your $PATH isn't a major security issue on its own. I'd classify
it at S3. The problem with S3s though, is that two separate S3s can combine to
create an S1 or an S0, which can bite you.

If you've had . in your PATH for a long time and never had a problem with it,
it's either because there isn't anything else open that makes this an issue
(fairly likely), or that no one's really bothered to exploit your system (also
fairly likely)

------
tfh
I never considered having "." in my $PATH because typing "./" is very
convenient in the us keyboard layout.

~~~
yason
Slightly off-topic but it seems to me that most keyboard layouts but the US
seem to be completely retarded—almost bordering a conspiracy—with regard to
usability when coding, using emacs and using the unix shell.

When I see someone coding with a non-us layout I smell the humble inexperience
and nod with compassion. The difference between layouts can be astonishing if
you only bang a lots of []{}|/\?-=+_-*()@#$'s. For some reason, computer
languages are full of those.

I use the us layout all the time except when I have to write something in my
native language and need the umlauts more easily. I remember the killing pain
of trying to write code in it until I realized I can just turn on the US
keyboard. Luckily, that was before my career...

~~~
xorglorb
Actually QWERTY was created to slow typists down. Back in ye olde days, when
typewriters were still around, there was the problem where people who typed to
fast would jam the typewriters. Thus, QWERTY was invented to slow people down
so the typewriters wouldn't jam. Then, when computers came along, everybody
knew QWERTY, so they continued using it.

~~~
stephencelis
That's an apocryphal story, though. QWERTY was said to have been invented,
actually, to make it easier for typewriter salesmen to type "TYPEWRITER", all
from the top row.

------
DrStalker
I avoid adding '.' to my path because I work on a lot of different linux and
unix systems as part of my job, and having a consistent command line I can use
without having to remember where I am and how I set things up is more
productive for me than saving a bit of time on my personal system.

For the same reason I don't use a custom .vimrc file; it's great when on a
configured system but causes problems elsewhere.

~~~
nitrogen
For years I held a similar philosophy, then I decided, "Screw it, I can just
copy .vimrc and .bashrc to whatever system I need, and if that's not possible,
I can adapt to the defaults." I haven't done too much customization yet, but
after seeing some example .vimrc and .bashrc files online, there's a lot of
potential for improving productivity.

~~~
goodside
Even better, keep them in a GitHub repository and include an installation
script. All the comforts of home in a carpet bag.

------
ludwigvan
I had tried this, and had makefiles fail because of this. It seems that if you
insist on saving $PATH this way, you should NOT to `export` it.

------
broofa
'Have had "." in my $PATH for 20 years. It's never been a problem... and
probably saved me several hundred thousand keystrokes.

Having to worry about there being an "ls" in the current dir is about the same
as worrying whether or not there are multiple versions of _any_ binary
elsewhere in $PATH.

This is a non-issue.

~~~
qwzybug

        wget http://some.dudes.site/cool_stuff.tar
        untar cool_stuff.tar
        cd cool_stuff
        ls
    

Oh but whoopsy-doodle, cool_stuff comes with this extra-cool script:

    
    
        cat ./ls
        
        #!/usr/bin/my-favorite-scripting-language
        
        do_sneaky_things :with => AllOfYourStuff && `rm -rf /`

~~~
stephencelis
If you're diligent to

    
    
      ls cool_stuff
    

before changing directories, it's less of an issue. And `rm -fr /' is less
likely than `rm -fr ~', since most people don't need root access to call `ls'.

But still, I don't add '.' to my path because the only time I directly
reference files in my current directory, it's because of a Zsh suffix alias.

------
daxelrod
Fun corollary to this, having an empty element in your $PATH (for example,
"/foo::/bar") is the same as having '.' in your $PATH, at least under bash.

This will usually happen when a login script puts the value of a variable in
your $PATH without actually checking whether that variable has any contents.

------
sendos
_This isn't 100% secure though - if you're a clumsy typist and some day type
"sl -l" instead of "ls -l", you run the risk of running "./sl"_

If you're a clumsy typist, even if you don't have '.' in your $PATH, you might
still type ./sl (instead of your intended ./ls) and get the "rogue" program to
run.

I've had . in my $PATH for the last couple of decades. It's fine.

~~~
goodside
The point is that you would never tpye "./ls" when you meant to type "ls".

Or at least I wouldn't. I just grepped through (several years of) my bash logs
and I have never once in my life typed "./ls", accidentally or otherwise. I
consider this strong evidence.

------
antfarm
Makes me think: the exploit he describes is the UNIX-predecessor of today's
web's XSS attacks ...

------
hackermom
I'm really surprised over the complete lack of thought shown by people who
spend time writing about this.

The problem isn't really about having . in your path, but the old mistake of
having it _AS THE FIRST THING_ in your path, before your shell has a chance to
reach its usual important locations (/bin, /sbin, /usr/bin, /usr/local/bin and
so forth). Put it as the last thing in your path variable and you won't be
having any problems worth mentioning (hey, even the OpenBSD guys finally went
with this solution after having banished . entirely for years).

~~~
tzs
What about those of us who aren't 100% perfect in our spelling and/or typing
of command names?

