[zilu:/tmp/k]ls -ls 1.ksh 2.ksh
8 -rwsr-xr-x 1 mwang other 21 Feb 7 06:40 1.ksh
8 -rwxr-xr-x 1 mwang other 21 Feb 7 06:40 2.ksh
> $0 is different when setuid. I need setuid and $0 to be the program name
> for the program to behave correct. Is there a workaround?
> [zilu:/tmp/k]ls -ls 1.ksh 2.ksh
> 8 -rwsr-xr-x 1 mwang other 21 Feb 7 06:40 1.ksh
> 8 -rwxr-xr-x 1 mwang other 21 Feb 7 06:40 2.ksh
I'm surprised your system *allows* setuid shells. Have you verified
that the shell in fact *does* run set-UID to the owner? (an '/bin/id'
in the script would do it - run it while logged in as somebody ELSE).
Set-UID shell scripts are almost always a *major* security problem,
starting with people who play games with IFS, and running to symlink
games(*) and race conditions....
You may also want to consider that #! causes re-reading of the
shell a second time (the source of many security holes with set-uid
scripts) - most likely, what you are seeing in the set-UID case is
that the kernel has reset argv to /bin/ksh because that's what's on
the #! line, and that's what's passed to the actual shell...
You might want to consider re-doing your program in a non-interpreted
language, or using a small secure set-UID helper written in C to launch
your script for you.
Computer Systems Senior Engineer
(*) Symlink attack:
PATH=.:$PATH # get . in your $PATH
ln -s /some/setuid/script ./-i # Create a symlink called '-i' to the script
-i # Run the script
So the script launches set-UID.. sees its argv starts with a -, which is
its cue to run as a login shell (that's how /bin/login and friends tell your
shell it's a login shell). So it runs the .profile/etc. However - $HOME
is *your* home directory, so it runs YOUR .profile with HIS permissions.
Install trojans, add salt, pepper, and other seasonings to taste....
I'm surprised at this. I would expect it to print something like
/dev/fd/3. On systems that allow setuid scripts, they avoid the link race
condition by specifying a file descriptor as the script name rather than
the actual file name. At least, that's how it works on Solaris; what OS
are you using? Maybe your OS doesn't have /dev/fd, but it runs the shell
with a special option that causes it to read the script from a file
descriptor rather than a filename.
In any case, when the system uses techniques like this to avoid the
race condition security problem, you lose the ability to find out the
script name (unless the system puts it into an environment variable).
Barry Margolin, bar...@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
You might look in $_
Opinions expressed herein are my own and may not represent those of my employer.