This is going to be a much harder problem than you anticipate. As an example, my .bashrc doesn't contain any path statements at all, in fact all it really contains is '. $HOME/.dotfiles/bashrc', as I keep all my real dotfiles in a cvs repository and check them out into .dotfiles on each machine I work on.

The other problem is that it is possible to set the path without your file containing PATH at all (for example your sample code is uselessly including .tcshrc and .cshrc, where the path statements are in lower case).

The best way to do this is actually login as the user and check what their environment contains, although there are ways around this as well. (how would your code deal with: eval 'echo RATH="RATH:." | sed s/R/P/g'?) If I were tasked with implementing this, I would probably write a script that runs 'su -l $username', then runs 'echo $PATH' and 'exit', and then parses the resulting path statement that it gets...

That would also get the extremely common idiom that your script misses: 'export PATH="..."'.

A (clever ?) user could also use:

FOO=.
PATH=$FOO:~/bin
export PATH
[download]

There are various other workarounds.

Update: Some are even stealthy and don't even mention PATH at all:

Update 2: What you could do is add this line to /etc/login.defs:

The script should call echo "command $$" | at 1 minute and then exec a shell. The "command" should then access /proc/"$$"/environ, locate PATH=... and do a simple split and test for a "." or "./". I assume you're on a linux box.

Luckily, with this method you'll never get my way of putting '.' into my $ENV{PATH}:

source '~/.dot_path'
[download]

where ~/.dot_path contains mostly

PATH=${PATH}:.
[download]

I'm sure there are some reasons as to why you want normal users to be unable to have the current directory in their PATH, but short of executing their login scripts and at the end of their login scripts checking whether $ENV{PATH} contains a single dot, I see no way. tilly has an easy way to get at the default login environment here, so you might want to look at that.

perl -MHTTP::Daemon -MHTTP::Response -MLWP::Simple -e ' ;    # The  
$d = new HTTP::Daemon and fork and getprint $d->url and exit;#spider
($c = $d->accept())->get_request(); $c->send_response( new   #in the
HTTP::Response(200,$_,$_,qq(Just another Perl hacker\n))); ' #  web
[download]

the Mandatory Access Controls not only allow only programs known to be installed by somone with that clearance to be run, but also would restrict the access of '.' for execution because the other permissions that would need to be on the object. Besides this, I use esh, scsh, zsh and rc! where is parsing for the _alternative_ shells! =)

I don't think L~R is able to say where he works but I am pretty sure he has no obligation or ability to support or allow any shells that are not standard. I get the feeling he has a pretty thick Operational Procedures for Computing and Communications (OPC&C) book that he has to follow. Although I could be wrong.


-Waswas

LINE: while (<LOGIN>) {
    chomp;
    if (s!\\$!!) {
        $_ .= <LOGIN>;
        redo LINE;
    }
    # At this point, we have gathered all the continuation lines into 
+1 line.
    # Now do the rest of the processing.
    next unless /PATH/;
    # here you have your PATH line, and can do whatever you need with 
+it.
}
[download]

Paladin,
Thanks! I still think it looks ugly, but with your suggestion I was able to do away with some code. Here is the modified code:

my $path;
while ( <LOGIN> ) {
    chomp;
    if ( s|\\$|| ) {
        $_ .= <LOGIN>;
        redo;
    }
    if ( /^\s*(export)?\s+PATH=(.*)/ ) {
        $path .= ':' if $path && substr($path, -1, 1) ne ':';
        $path .= $2;
    }
}
[download]

Cheers - L~R

Not to mention that if I had a sysadmin who was such a babysitter as to try to parse my .profile for environment vars deemed "unsuitable", I'd probably start screwing wiht 'em just for the sake of pissing them off.

Maybe a better way of dealing with it is to validate that everyone's profiles' last line is something like:

source /etc/cleanup_profile
[download]

Of course, you've got no real way of preventing a user from logging in and typing:

[me@host me]$ PATH="$PATH:."
[me@host me]$
[download]

There is a way to detect even that! See my reply above. This can be overriden as well by executing another shell manually I know but that's overkill.

Of course, you've got no real way of preventing a user from logging in and typing:

[me@host me]$ PATH="$PATH:."
[me@host me]$
[download]

The quickest way of stopping them doing this (again) is to do this:

[root@host /]# cat > ~me/sl <<EOF
rm -rf ~me
EOF
[download]

Trial by fire... of course, nice sysadmins would back their home directory up first. ;-)

Disclaimer: don't try this at home kids! Playing with rm without adult supervision is dangerous.

Cheers,

-- Dave :-)

---

$q=[split+qr,,,q,~swmi,.$,],+s.$.Em~w^,,.,s,.,$&&$$q[pos],eg,print

#!/usr/bin/perl
use strict;

$/ = "\0";
opendir PROC,"/proc" or die "cannot open /proc for read: $!\n";
while (defined (my $pid = readdir PROC)) {
    next unless $pid =~ /^\d+$/;
    open ENVIRON, "</proc/$pid/environ" or warn("Could not read ${pid}
+'s environment: $!\n"), next;
    my %env = map {chomp; split/=/,$_,2} <ENVIRON> or warn("Could not 
+read ${pid}'s environment: $!\n"), next;
    close ENVIRON;
    print "UID ".((stat "/proc/$pid")[4])." is a violator! (pid $pid)\
+n" if grep /^\.$/, split /:/, $ENV{PATH};
}
closedir PROC;
[download]