\"special\" shells a security hole?
robert at gitpyr.UUCP
robert at gitpyr.UUCP
Mon Feb 9 23:59:06 AEST 1987
>dce at quacky.UUCP (David Elliott) (dce at quacky.UUCP, <169 at quacky.mips.UUCP>):
>
> The idea of using the SHELL environment variable is something that
> really wreaks havoc when you port the System V.2 or better version
> of make(1) to a BSD system (or use it in System V.3). Take a look
> around and count how many makefiles would break if run using csh
> instead of sh. The person that came up with this method really needs
> a talking to. We ended up changing sh to not import the value of
> SHELL from the environment. If a makefile needs to use a different
> shell, it should be specifiable on a per-makefile basis, instead
> of having the user screw something up unknowingly.
> shell, the user can just
>
On a 3B20 running SVR2.0v2, the shell IS specifiable on a per makefile
basis. Just include "SHELL=/bin/sh" near the beginning of the makefile.
I'm fairly sure the same applies to SVR3.0 (can't tell right now, my 3B2
died of a power failure last night and I haven't brought it back up
yet).
According to the manual page, macro definitions in the makefile are
processed AFTER the environment variables are processed, which means
that macro definitions override environment variables where-ever a
conflict occurs. (Unless, of course, you use the -e option.)
robert
--
Robert Viduya robert at pyr.ocs.gatech.edu
Office of Computing Services (404) 894-4660
Georgia Institute of Technology
Atlanta, Georgia 30332
More information about the Comp.unix.wizards
mailing list