[Menu Bar]

Dot (".") Not In Default PATH

Introduction

In Unix, every directory contains a subdirectory named "." (a single period), which refers to the directory itself. You may "cd" to ".", you may list it (ls -ld .), and you may include it in path specifications where it acts as an alias for the "current directory."

Previously, ARSC had included "." in the system-supplied PATH. The effect of this was that, to run an executable, users could simply "cd" to the appropriate directory and type the name of their script or binary. For instance:

 indigo21% cd ~/programs
 indigo21% ls -la

 drwx------ 3 userid usergrp 4096 Apr 23 11:44 .
 drwx------ 32 userid usergrp 4096 May 30 14:05 ..
 -rwx------ 1 userid usergrp 1524968 Apr 21 18:30 a.out

 indigo21% a.out

The program a.out ran because the user's environment variable PATH included the directory ".". Here is a sample PATH:

 indigo21% echo $PATH

 /usr/sbin:/usr/bsd:/sbin:.

The system reads the PATH variable to obtain the list of directories to search. Thus, it searches, in order, for the following executables:

 /usr/sbin/a.out
 /usr/bsd/a.out
 /sbin/a.out
 ./a.out

and runs the first found. Had the user named her program "ls" rather than "a.out", then the command:

 indigo21% ls

would cause the system to search for:

 /usr/sbin/ls
 /usr/bsd/ls
 /sbin/ls
 ./ls

and to run "/sbin/ls" (the first "ls" found). To run her own program "ls", she would need to disambiguate the request by typing its path:

 indigo21% ./ls

Whenever the shell detects an explicit path preface to a command (such as "./") it ignores the PATH variable, and does not do a search.

Security Risk

When a command is not prefaced by an explicit path, you do not always know from which directory it will run. This introduces some uncertainty into your work.

Worse, when "." is in your PATH, it introduces a well-known security risk. A person, possibly malicious, having gained access to the system, can place "trojan horse" programs in various directories in the hopes that someone with "." in their PATH will eventually run them.

Here's a simple example: the hacker finds a world writable directory below /tmp, and plants a program there called "mroe". If "." were in a user's path, and if the user were to "cd" into the directory, and then were to mistype "more" as "mroe", the user would run the "trojan horse."

However, if "." were not in the user's path, then the shell's search for the program "mroe" would fail, and the shell would return an error message, such as, "command not found."

Serious Risk

The risk is considerably greater if "." is the first directory listed in PATH.

Using the previous example, if "." were the first directory in PATH, then the hacker could simply name the program "more" or "ls". It is nearly certain that the user would eventually cd to the directory, type "ls", and thus run the "trojan horse."

Working Without "."

Why ARSC has Removed "." From the System-Supplied PATH

ARSC seeks improvement in system security. It is inconsistent with this goal for the system itself to support "." in PATH.

How to Proceed Without "." in Your PATH

Without "." in your PATH variable, you must specify the path "./" explicitly when you run executables from the current directory. This is true whether you run interactively or from scripts, including NQS scripts.

For instance, here is an interactive session in which the user runs the program a.out from the current directory, and then runs it again, piping its output into a perl script:

 indigo21% ls -la
 drwx------ 3 userid usergrp 4096 Apr 23 11:44 .
 drwx------ 32 userid usergrp 4096 May 30 14:05 ..
 -rwx------ 1 userid usergrp 1524968 Apr 21 18:30 a.out
 -rwx------ 1 userid usergrp 449 Jun 10 18:30 my_sort.perl

 indigo21% ./a.out 
 indigo21% ./a.out | ./my_sort.perl

Cray NQS users must specify explicit paths in their qsub scripts. Here is part of Example #2 from "http://www.arsc.edu/user/UsingNQS.html":

 #QSUB -lM 128Mw # limit the request to 128 Mw
 #QSUB -lT 10000 # limit the request to 10000 CPU seconds

 cd ~/project # Go to project directory
 cft77 loop.f # Compile a program called loop.f
 segldr loop.o # Load replaceable loop.o as a.out
 ./a.out # Execute the program a.out

Another alternative for scripts, including qsub scripts, is to append "." to PATH in the local shell:

Korn Shell Users: Add to the top of scripts

 PATH=${PATH}:.
 
 C Shell Users: Add to the top of scripts
 setenv PATH ${PATH}:.

Placing "." in Your PATH

ARSC strongly encourages you to learn new computer habits and rewrite your scripts so that you may proceed without "." in your PATH.

However, if you choose to accept the risk and include "." in your PATH, ensure that it follows the system-supplied directories. Simply append it to the end of the system-supplied PATH, as follows:

Korn Shell Users: Add to your .profile file:

 PATH=${PATH}:.

C Shell Users: Add to your .cshrc file:

 setenv PATH ${PATH}:.

More Information

Please contact User Support if you have any questions or problems.
You may also wish to review the ksh or csh man pages.

Arctic Region Supercomputing Center
PO Box 756020, Fairbanks, AK 99775 | voice: 907-450-8600 | email: