> From: donna garverick
> --- Gehan Gehale <[log in to unmask]> wrote:
>
> > log on as manager.sys
> > : chgroup hpbin
> > : sh
> > $ LS
> > (I get a list)
>
> capital LS works??? without ./ in front??
What Donna isn't saying, but rather implying, is that "shell" commands are typically lower case -- posix/unix is case sensitive when it comes to commands [and options to commands], so it is surprising [in a way] to see someone explicitly type "LS", especially after using lower-case commands in MPE-space (for chgroup and sh).
> it sounds too
> like perhaps someone has added '.' to your path. that's a bad thing
> and should be removed.
Since we don't generally use "the shell" around here ourselves, our system is pretty generic; here are some interesting results:
shell/iX> env | grep PATH
HPPATH=!hpgroup,XEQ,XEQ.USAVID,PUB,PUB.SYS,LASER.LARC,PUB.VESOFT
PATH=/usr/local/bin:/bin
MAILPATH=/usr/mail/MGR.COREDEV
MANPATH=/usr/local/man:/usr/man:
shell/iX> ls -l BUG*
-rwxr-x--- 1 MGR.COREDEV COREDEV 9840 Dec 5 2003 BUGGER
-rwxr-x--- 1 MGR.COREDEV COREDEV 6320 Sep 30 2003 BUGIN200
-rwxrwxrwx 1 MGR.COREDEV COREDEV 25856 Sep 8 15:20 BUGVER
shell/iX> BUGVER
BUGVER: not found
shell/iX> ./BUGVER
BUGVER : A.00.02
Execute the MPE command 'VERSION' against this program to see the results
shell/iX> exit
988/COREDEV/TEMPTE:bugver
BUGVER : A.00.02
Execute the MPE command 'VERSION' against this program to see the results
988/COREDEV/TEMPTE:
so I'll agree with Donna in that "someone has added '.' to your path". This is equivalent to the "!hpgroup" that you see in the HPPATH variable [which, come to think of it, is (a) just as bad, and (b) totally unneccessary as this is MPE's default behaviour, unless someone changed things to ALWAYS search the HPPATH for the location of an executable]
The reason this is "bad", in your example, is because the "system manager", or "root" user in unix parlance, can do ANYTHING to your system. Also, the "path" value is ALWAYS evaluated, in order, to determine the location of the executable for any given command. This is usually exploited by a "clever programmer" who writes a program called, for example, "ls" and leaves it in their home directory [or any directory to which they can write and is executable]. This type of program usually does at least two things:
1) something unspecified, but generally presumed to be "nasty" from a security standpoint [perhaps it creates a user in /etc/passwd that is a root-equivalent user]
2) executes the real "ls" command
3) [and if the programmer is really good at covering their tracks] filters the output of the above command in order to remove any trace of the fact that the PROGRAM "ls" resides in the current directory.
4) sends an e-mail to some unspecified [usually off-site] account indicating that it was successful back in step 1
If an "ordinary" user executes this program, intentionally or otherwise, the "add a user" step will likely fail, although the program will silently ignore this and continue on. If a "super-user", however, runs this, then a "back-door" is opened in your system. Of course, you say to yourself, "but *I* wouldn't ever run such a program!", however the point is that should you ever "cd" into this malicious user's home directory [perhaps he cons you into doing this by saying he's having trouble with something and wants your opinion], then any ordinary command is a potential land-mine waiting for you to step on it.
(which, BTW, is why you should use the command "su -" instead of "su" by itself on a unix/linux system -- the "-" specifies that the actual "root user's" profile/environment should be loaded rather than continuing on in whatever context you issued the "su" command, which again could be some "ordinary user" who like to have "." in his path...)
SERENDIPIDOUS NOTE: As I was writing this, someone here asked me a question about setting a variable in "unix", and I realized that setting "environment" variables in the posix shell is SLIGHTLY unlike MPE variables -- in particular, whenever you execute a command, that "command" actually runs within it's OWN environment, so if you type at a system prompt:
shell/iX> set PATH=/usr/local/bin:/bin:~/bin
and then issue an "env" command to display the current variables, strangely enough, "PATH" doesn't get changed. The reason is as I said: the (set) command runs in it's "own" environment, sets the variable, then returns to your "actual" environment where the variable isn't really changed. When you issue the "env" command, it too executes in it's "own" environment, and it inherits the value from the PARENT environment [which was never changed], and ultimately causes premature baldness in first-time unix programmers...
The command you need is "export", which will copy the value as it exists in a "sub" shell back to the parent shell, but you'll still run into a catch-22 here:
shell/iX> set PATH=something
shell/iX> export PATH
does NOTHING -- when you return to the command prompt from the "set" command, PATH is already back to what it was before, and [equally strange, but logical if you follow along], "export" gets the value of PATH from the parent, and thus "exports" it back unchanged. To do this "interactively", you actually need to type:
shell/iX> export PATH=somewhere:else
(which, per the man page, the "=newvalue" is actually an optional part of the command)
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
