rich@rexago1.UUCP (K. Richard Magill) (11/25/85)
On SV.2 (3b2, pc7300 (Safari)) suid bits do not work on shell scripts. Am I just silly or don't I remember them working on 2 other UN*X-ish (TNIX, XENIX) environments? K. Richard Magill
bamford@ihuxw.UUCP (h. bamford) (11/27/85)
> On SV.2 (3b2, pc7300 (Safari)) suid bits do not work on shell scripts. Am > I just silly or don't I remember them working on 2 other UN*X-ish (TNIX, > XENIX) environments? > Suid bits on shell scripts don't work on any machine I have ever used. This includes PDP-11/70, Vax, 3b20, U370, PC7300. It is frustrating, but I have wound up making up a little C program which execs the shell. The C program has the suid bit set... -- Harold Bamford AT&T Bell Labs Naperville, Ill (cornet) 8-367-5744 (312) 979-5744 (work)
rt@cpsc53.UUCP (Ron Thompson) (11/27/85)
> On SV.2 (3b2, pc7300 (Safari)) suid bits do not work on shell scripts. Am > I just silly or don't I remember them working on 2 other UN*X-ish (TNIX, > XENIX) environments? They have never worked on any SysV.(2 or no) that I have ever used. -- Ron Thompson AT&T Information Systems Customer Programming (404) 982-4217 Atlanta, Georgia Services Center ..{ihnp4,akgua}!cpsc53!rt (Opinions expressed are mine alone.)
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (11/27/85)
> On SV.2 (3b2, pc7300 (Safari)) suid bits do not work on shell scripts.
Eek, I should hope not! Can you say "Security hole big enough
to drive a truck through?" I knew you could!jsdy@hadron.UUCP (Joseph S. D. Yao) (11/28/85)
In article <123@rexago1.UUCP> rich@rexago1.UUCP (K. Richard Magill) writes: >On SV.2 (3b2, pc7300 (Safari)) suid bits do not work on shell scripts. Am >I just silly or don't I remember them working on 2 other UN*X-ish (TNIX, >XENIX) environments? Setuid bits never used to work on shell scripts, because the shell scripts were/are not executed -- the s h e l l is/was executed with the script name as argument. In 4BSD and 4BSD-ische systems, if the first two chars in a shell script are "#!" and the rest of the first line is the name of a program (most often a shell) to run with that script as input, then the kernel runs that program, but some other effects are as if the script had been directly executed; e.g., the setuid and getuid bits are honoured. Note that on non-4BSD-ische systems where the C shell emulates this behaviour, the side effects still don't exist because the kernel is not doing the executing. -- Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}
edward@ukecc.UUCP (Edward C. Bennett) (11/28/85)
In article <114@brl-tgr.ARPA>, gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) writes: > > On SV.2 (3b2, pc7300 (Safari)) suid bits do not work on shell scripts. > > Eek, I should hope not! Can you say "Security hole big enough > to drive a truck through?" I knew you could! I've heard that said about shell scripts many times, but no one has ever explained why. Could some knowledgeable soul fill me in please? Thanks much, -- Edward C. Bennett UUCP: ihnp4!cbosgd!ukma!ukecc!edward /* A charter member of the Scooter bunch */ "Goodnight M.A."
guy@sun.uucp (Guy Harris) (11/29/85)
> > On SV.2 (3b2, pc7300 (Safari)) suid bits do not work on shell scripts. Am > > I just silly or don't I remember them working on 2 other UN*X-ish (TNIX, > > XENIX) environments? > > Suid bits on shell scripts don't work on any machine I have ever used. > This includes PDP-11/70, Vax, 3b20, U370, PC7300. It is frustrating, > but I have wound up making up a little C program which execs the shell. > The C program has the suid bit set... Set-UID bits don't work on shell scripts, in general, because for them to work the shell'd have to be running set-UID. If you're running a shell as yourself, and it tries to run a shell script which is set-UID to "root", how would it be able to get "root"s privileges? And if *it* could get root privileges, what would prvent some program you wrote like main() { system("rm -rf /"); } from getting them as well? In some systems (4.1BSD, 4.2BSD, Version 8, and some others which have added this feature - originally concocted by Dennis Ritchie), you can have the kernel detect a shell script and run a shell (or other interpreter) on that script. In this case, you *can* have set-UID shell scripts; the kernel is trusted code (yuk yuk) and can give the shell it's firing off to run the set-UID script the appropriate privileges. However, there is a horrible security hole in this; I think there's a fix, but I don't know if it closes all the holes, and it involves changing any and all shells and other interpreters - a minor change, but still a change, and you need source to change it. So don't set up set-UID shell scripts if you don't trust your user population. Guy Harris
henry@utzoo.UUCP (Henry Spencer) (11/29/85)
> > Eek, I should hope not! Can you say "Security hole big enough > > to drive a truck through?" I knew you could! > > I've heard that said about shell scripts many times, but no > one has ever explained why. Could some knowledgeable soul fill me > in please? Basically because the interpretation of shell scripts is much more a function of context than is the case for C programs, and the shell script has less control over the context. Writing bullet-proof setuid programs in C is extremely difficult; most existing setuid programs can be induced to fall over or misbehave if you work at it hard enough. In the shell it's far worse. Consider the effect of running a setuid shell program with a nonstandard value of IFS set -- the interpretation of the shell script will bear no relation to what the writer intended. This problem can be solved, but there are ten more lurking deeper in. The shell is simply too complex to permit *confidence* that there are no further holes, given that such confidence is very difficult to achieve even in C. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry