When . is valid in PATH

[Gregg Wonderly]

	Here at OKSTATE, Mark Vasoll came up with a surprisingly simple, and
quite neat method of resolving the problems with '.' being in your directory
path.  I immediately added this to MY shell, Vish, and thought that I would
bring it to the attention of the NET, and see what others think.

	The idea is to create another NON-exportable environment variable that
holds a list of ROOT directories under which '.' is considered when looking
for the executable for a particular command.  Before DOT is allowed, the
PWD must have as its' ROOT, one of the given strings.  My shell keeps its'
own copy of PWD, so this does not involve a process, or other high overhead
of establishing the PWD.  Also note that '.' must also explicitly appear in
the PATH variable before these actions are taken.  If no 'dotpath' is
established, then normal behavior is 'anything goes'.  At startup, Vish
establishes the user's home directory as given in /etc/passwd as the sole
directory for 'dotpath'.

	When a particular executable is found to exist in '.', and it is the
name of the reqested command, and 'dotpath' does not contain a leading
substring of PWD, then a message similiar to

	'command': Current directory is not safe!

is printed, and 'command' is not executed.  I am sure that somebody else
may have thought of something of this nature, but I have yet to come
across it.  On some systems (Really, there are non-destructive users out there),
the security hole that '.' creates is not a problem, but all it takes is one
time to make you a bit paranoid.  Since the latest trend in computing magazines
seems to be TELL THE WORLD HOW TO BREAK THE SYSTEM, this type of feature
can provide some comfort.  Of course, it relies on your own decision as to
what 'dotpath' should be.  My particular implementation makes it natural to 
use ":" as 'dotpath', and then DOT is never considered as valid.

	I would be interested in hearing other's ideas and views on this subject.
DOT can be a great convienence, but we all know the consequences if you
use it in a directory writable by others.


Gregg Wonderly
Department of Computing and Information Sciences
Oklahoma State University

UUCP: {cbosgd, ea, ihnp4, isucs1, mcvax, uokvax}!okstate!gregg
ARPA:  gregg%okstate.csnet at CSNET-RELAY.ARPA  
    or
ARPA:  gregg at A.CS.OKSTATE.EDU