Path: utzoo!mnetor!uunet!munnari!mwp
From: mwp@munnari.oz (Michael Paddon)
Newsgroups: comp.unix.wizards
Subject: Re: access(2) (was: Writing to A NON-Existing File in "C")
Message-ID: <2089@munnari.oz>
Date: 22 Apr 88 03:18:02 GMT
References: <975@unmvax.unm.edu>
Organization: Comp Sci, Melbourne Uni, Australia
Lines: 53

in article <975@unmvax.unm.edu>, mike@turing.UNM.EDU (Michael I. Bushnell) says:
>
>>Is there any legitimate reason why someone might take a program which was
>>not originally designed to run setuid or setguid and do chmod u+s
>>or chmod g+s to it?
> 
> Not really.  But there is another way it can run under suid
> conditions:
> 
> % whoami
> foo
> % su
> Password:
> # nifty_program
> 
> Note that nifty program will now have REAL uid foo and EFFECTIVE uid
> root.

"Su" on all the BSD and SunOs systems I have come across changes
both the real and effective uid/gid and the group access list.
If this were not so, many programs would not run from a "su" shell
because their authors used "access". :-) Your "su" behaviour is,
perhaps, System V madness.

In answer to the query above:
=============================
Server processes and the like are often setuid "nobody" even if
they were never originally designed to be run so (and never
take advantage of the fact). This basic security precaution
can forestall many problems.

While this was sufficient in earlier Unix versions, the ability
to swap uid/euid or to set either one to the other that BSD
now provides means that the setuid program must explicitly
revoke any priveleges that may exist.

Consider a server program (setuid "nobody") which runs arbitrary object
sent to it and which is started up by root in "rc.local". This is a
real life example -- we have one like this running at Melbourne Uni
right now.

The moral is that it is never safe to make an arbitrary program setuid.
Given the latitude allowed by current UNIX kernels in manipulating uids
a program needs to know it is setuid to take advantage of the fact, or
to cover possible security problems.

                                         Michael Paddon
                                         ==============

===========================
UUCP:	{seismo,mcvax,ukc,ubc-vision}!munnari!mwp
ARPA:	mwp%munnari.oz@seismo.css.gov
CSNET:	mwp%munnari.oz@australia