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!
geoff@ISM780B.UUCP (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 don't work on shell scripts on Sys 3 or Sys 5, I suppose this is for security reasons. As far as I know, they don't work on any AT&T UNIX. I don't know about other UNIX-ISH systems, but most of them are BSD derived, so I wouldn't be surprized. (For those net-landers who are confused, the Safari is also known as the 6300PLUS, and has roughly the same relationship to the 6300 as the IBM/PC/AT has to the XT.) Geoffrey Kimbrough {decvax!vortex || ihnp4!allegra!ima}!ism780!geoff "As usual, if you or any of your opinions are caught or killed, the secretary will disavow any knowledge of your actions".
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
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (11/29/85)
> Suid bits don't work on shell scripts on Sys 3 or Sys 5, I suppose this is > for security reasons. As far as I know, they don't work on any AT&T UNIX. Since the script is interpreted by the shell, and since the shell does not run set-UID itself, of course you can't have set-UID shell scripts. For that to work, the kernel itself would have to run the shell for you (as in 4.2BSD for #! magic numbers), after establishing suitable privilege for it. The shell was not designed with this usage in mind, so it has numerous security loopholes. Closing them all is a big task.
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
slb@bnl44.UUCP (San Barr lying around @ The Beach (slb @ Brookhaven Nat. Labs, L.I.)) (12/11/85)
> (For those net-landers who are confused, the Safari is also known as > the 6300PLUS, and has roughly the same relationship to the 6300 > as the IBM/PC/AT has to the XT.) > Geoffrey Kimbrough {decvax!vortex || ihnp4!allegra!ima}!ism780!geoff The UNIX PC (7300) is referred to as the Safari Four. As far as AT&T making reference to the 6300+ as the Safari, I find it hard to belive as well as overly confusing. -- Sanford L. Barr | Voice phone: (516) 736-4155 Famous designer of the Write Only Memory.| Address (USnail): -- -- | ..!decvax!mcnc!philabs!sbcs!bnl44!slb | Almagmated Tech. ...slb@bnl44.ARPA | 39 Royalston La. ...slb@bnl44.UUCP | S. Setauket, N.Y. 11720 ...slb@bnl44.bitnet | ATTN: Sanford L. Barr ----------------------------------------------------------------------- "Did you exchange a walk-on part in a war for a lead role in a cage?"
geoff@ISM780B.UUCP (12/19/85)
>/* Written 9:24 pm Dec 10, 1985 by slb@bnl44 in ISM780B:net.unix */ >> (For those net-landers who are confused, the Safari is also known as >> the 6300PLUS, and has roughly the same relationship to the 6300 >> as the IBM/PC/AT has to the XT.) > The UNIX PC (7300) is referred to as the Safari Four. As far >as AT&T making reference to the 6300+ as the Safari, I find it hard >to belive as well as overly confusing. Hmm, perhaps I was too terse, the 6300+ is refered to as a Safari Five (or V). Confusing maybe, but TRUE. (I didn't know the 7300 was a Safari Four, sorry about that.) It just goes to show you that trying to unconfuse netlanders is futile. 8^) Geoffrey Kimbrough -- Director of Dangerous Activities -- INTERACTIVE Systems Corporation, Santa Monica California. {decvax!vortex || ihnp4!allegra!ima}!ism780!geoff The virtues of doors, windows, and teacups lie precisely in those parts which are empty.
rlk@chinet.UUCP (Richard L. Klappal) (12/22/85)
In article <1029@bnl44.UUCP> slb@bnl44.UUCP (San Barr lying around @ The Beach (slb @ Brookhaven Nat. Labs, L.I.)) writes: >> (For those net-landers who are confused, the Safari is also known as >> the 6300PLUS, and has roughly the same relationship to the 6300 >> as the IBM/PC/AT has to the XT.) >> Geoffrey Kimbrough {decvax!vortex || ihnp4!allegra!ima}!ism780!geoff > > The UNIX PC (7300) is referred to as the Safari Four. As far >as AT&T making reference to the 6300+ as the Safari, I find it hard >to belive as well as overly confusing. >-- And to add to the confusion, the 'growed-up' 7300 UNIX/PC just delivered to our lab (2Meg x 40Meg) is now a 3B1. -- --- UUCP: ..!ihnp4!chinet!uklpl!rlk || MCIMail: rklappal || Compuserve: 74106,1021 ---
shor@sphinx.UChicago.UUCP (Melinda Shore) (12/24/85)
[] According to our AT&T rep, the product line is labelled something like this: 6300 Plus <--> 6700 7300 <--> Safari beefed up 7300 <--> 3b1 "Safari" was the name used to describe the 7300 while it was under development, and doesn't seem to have anything to do with the micros based on Intel processors. -- Melinda Shore ..!ihnp4!gargoyle!sphinx!shor University of Chicago Computation Center Staff.Melinda%chip@UChicago.Bitnet " ... a statement made while looking backwards will have its wrong end in front." [F. Huxley]