Date: Sat, 18 Sep 2004 20:37:50 +0000 From: Richard Bradley <rtb27@cam.ac.uk> To: Matthew Seaman <m.seaman@infracaninophile.co.uk>, mailing lists at MacTutor <lists@mactutor.biz> Cc: freebsd-questions@freebsd.org Subject: Re: how to make an executable run as another user Message-ID: <200409182037.50882.rtb27@cam.ac.uk> In-Reply-To: <20040918113149.GC38377@happy-idiot-talk.infracaninophile.co.uk> References: <200409171950.19717.rtb27@cam.ac.uk> <A21CB3BE-08EB-11D9-8547-000A95775140@mactutor.biz> <20040918113149.GC38377@happy-idiot-talk.infracaninophile.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
I understand now. Thanks very much for all your help. Rich On Saturday 18 September 2004 11:31 am, Matthew Seaman wrote: > On Fri, Sep 17, 2004 at 04:53:31PM -0400, mailing lists at MacTutor wrote: > > QUOTE: "In most UNIX kernels there exists what is called a 'race > > condition' when executing scripts. Scripts are pieces of code which are > > interpreted by, strangely enough, interpreters. Common examples of > > interpreters are perl, sed, and awk. So when you have in your perl code > > #!/usr/local/bin/perl it tells the operating system to start executing > > the perl interpreter with the current script as input. Between the time > > that the perl interpreter starts executing and the time that it reads > > in your script the 'race condition' exists. At this time, a mischievous > > person could 'win the race' and be able to replace your script with > > another. And if your script is running as setuid, that person's script > > would run as your user! So their script could do anything that you > > could do from the command line. As a result, most UNIX kernels will > > disable users from running scripts as setuid. The most common way > > around this is to create a wrapper program around your script. A > > wrapper, in this context, is a small program, possibly written in C, > > that when executed will simply run your script. The 'race condition' > > does not exist for real executables and so you won't be thwarted by the > > kernel itself." > > Actually, this should no longer be a problem in any up to date version > of Unix. The race condition between the kernel reading the script to > find what interpreter to invoke, and the interpreter then to read and > interpret the script was solved by having the kernel pass an open > filedescriptor on the script file to the interpreter. One way of > testing if your OS supports this is the presence of 'file descriptor' > devices under /dev -- eg. under FreeBSD you get: > > happy-idiot-talk:/usr/local/etc:% ls -la /dev/fd/* > crw-rw-rw- 1 root wheel 22, 0 Jul 5 17:08 /dev/fd/0 > crw-rw-rw- 1 root wheel 22, 1 Jul 5 17:08 /dev/fd/1 > crw-rw-rw- 1 root wheel 22, 2 Jul 5 17:08 /dev/fd/2 > crw-rw-rw- 1 root wheel 22, 3 Jul 5 17:08 /dev/fd/3 > crw-rw-rw- 1 root wheel 22, 4 Jul 5 17:08 /dev/fd/4 > crw-rw-rw- 1 root wheel 22, 5 Jul 5 17:08 /dev/fd/5 > crw-rw-rw- 1 root wheel 22, 6 Jul 5 17:08 /dev/fd/6 > crw-rw-rw- 1 root wheel 22, 7 Jul 5 17:08 /dev/fd/7 > crw-rw-rw- 1 root wheel 22, 8 Jul 5 17:08 /dev/fd/8 > crw-rw-rw- 1 root wheel 22, 9 Jul 5 17:08 /dev/fd/9 > [...] > > However, the horror has been so beaten into the collective unconscious > inherited from earlier days of Unix that shell scripts are still > automatically stripped of any setuid or setgid bits by default on most > Unix variants. I did see a setuid 'lp' script as a standard part of > the lp system on a Solaris 8 box once -- took me a long time to > convince myself it was actually safe. > > Cheers, > > Matthew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200409182037.50882.rtb27>