Date: Sat, 18 Sep 2004 12:31:49 +0100 From: Matthew Seaman <m.seaman@infracaninophile.co.uk> To: mailing lists at MacTutor <lists@mactutor.biz> Cc: Richard Bradley <rtb27@cam.ac.uk> Subject: Re: how to make an executable run as another user Message-ID: <20040918113149.GC38377@happy-idiot-talk.infracaninophile.co.uk> In-Reply-To: <A21CB3BE-08EB-11D9-8547-000A95775140@mactutor.biz> References: <200409171950.19717.rtb27@cam.ac.uk> <A21CB3BE-08EB-11D9-8547-000A95775140@mactutor.biz>
next in thread | previous in thread | raw e-mail | index | archive | help
--NKoe5XOeduwbEQHU
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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 =20
> condition' when executing scripts. Scripts are pieces of code which are =
=20
> interpreted by, strangely enough, interpreters. Common examples of =20
> interpreters are perl, sed, and awk. So when you have in your perl code =
=20
> #!/usr/local/bin/perl it tells the operating system to start executing =
=20
> the perl interpreter with the current script as input. Between the time =
=20
> that the perl interpreter starts executing and the time that it reads =20
> in your script the 'race condition' exists. At this time, a mischievous =
=20
> person could 'win the race' and be able to replace your script with =20
> another. And if your script is running as setuid, that person's script =
=20
> would run as your user! So their script could do anything that you =20
> could do from the command line. As a result, most UNIX kernels will =20
> disable users from running scripts as setuid. The most common way =20
> around this is to create a wrapper program around your script. A =20
> wrapper, in this context, is a small program, possibly written in C, =20
> that when executed will simply run your script. The 'race condition' =20
> does not exist for real executables and so you won't be thwarted by the =
=20
> 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
--=20
Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks
Savill Way
PGP: http://www.infracaninophile.co.uk/pgpkey Marlow
Tel: +44 1628 476614 Bucks., SL7 1TH UK
--NKoe5XOeduwbEQHU
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (FreeBSD)
iD8DBQFBTByliD657aJF7eIRAp5eAJ41hDaavLdaoMrhFdSvGCe+a6q2eQCbBEpD
T0ErSlPgHqwhNhiis4HcMh0=
=Gmgs
-----END PGP SIGNATURE-----
--NKoe5XOeduwbEQHU--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040918113149.GC38377>