Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!usc!snorkelwacker.mit.edu!ai-lab!life.ai.mit.edu!rearl From: rearl@gnu.ai.mit.edu (Robert Earl) Newsgroups: comp.unix.aix Subject: Re: bsh & ksh running setuid Message-ID: Date: 30 Apr 91 00:35:00 GMT References: <1991Apr29.132514.8361@eagle.lerc.nasa.gov> <1991Apr29.200328.5668@ico.isc.com> Sender: news@ai.mit.edu Organization: (EVIL!) Lines: 28 In-reply-to: rcd@ico.isc.com's message of 29 Apr 91 20:03:28 GMT In article <1991Apr29.200328.5668@ico.isc.com> rcd@ico.isc.com (Dick Dunn) writes: | fsfrick@bones.lerc.nasa.gov (David Fricker) writes: | > FYI: under AIXv3.1 release 3003, bsh & ksh do NOT ignore the | > setuid bits when running a script... | ... | > So, if you want scripts to run setuid and you have release 3003, you | > may want to save a copy of the bsh & ksh binaries. | | 1. I'm not clear on how this is a property of the shells, rather than | the OS. Seems that the shell isn't going to be able to alter its own uid; | it needs kernel help at exec() time. I talked to the original poster because I was unclear as well; we determined this: The shell finds out if it's running setuid, and if so, refuses to continue interpreting the script. A noble idea, I suppose, but it's 1) Too Late and 2) not the shell's place to decide! | 2. For those who haven't run into this before: Note that setuid shell | scripts are a security sieve. Indeed. What's going to stop trusting_sysadmin from writing a faulty awk or bash script? Please note that I'm not advocating or questioning disabling setuid scripts from within the kernel, I'm only saying that putting this responsibility in the shell is asking for trouble. --robert