John Ollason wrote:
I am just an ordinary user who has used UN*X operating systems on Suns since the dawn of time. I have _always_ set . in my path in the login script in my accounts on my linux machines. Indeed it has always been present in the standard login scripts provided to the average user on the machines on which I have had accounts. After frying one of the lib files with a frivolous update that went wrong I once had to crank up sash to replace the file and I was stalled for ages until I remembered that I had to be explicit about the current working directory. So, what's the problem? Have I been juggling with running chainsaws all these years?
(It is off topic, and kind of a Unix FAQ. Actually, it's not strictly limited to Unix -- the same will probably apply when using a shell on a multi-user, say Mac OS or Windows, system.)
The problem is that a local attacker can place a malicious program under a common name (ls, dir, or whatever) in a world-writable directory such as /tmp. So when you're in that directory and enter this command with . in your $PATH, you will execute the malicious program (which then can, of course, do anything in your name and give the attacker almost unlimited control of your account).
BTW, what I do for GPC programs (to remain a little on-topic) is to place the executables in a fixed directory (--executable-path=$HOME/bin, or whichever directory you prefer) and put that directory (which is, of course, only writable by me, and with an absolute directory name) in my $PATH. Apart from the problem with ., it also prevents executables from lying around in various working directories.
Frank