Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!lll-tis!ames!ncar!oddjob!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.unix.wizards
Subject: Re: access(2) (was: Writing to A NON-Existing File in "C")
Message-ID: <11144@mimsy.UUCP>
Date: 20 Apr 88 22:56:11 GMT
References: <9654@jplgodo.UUCP> <14020030@hpisod2.HP.COM> <887@cresswell.quintus.UUCP>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 32

In article <887@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard
A. O'Keefe) writes:
>If a program which is never intended to run setuid ensures that it is
>not being run setuid or setgid by doing
[edited]
>	if (geteuid() != getuid() || getegid() != getgid()) {
>	    fprintf(stderr, "%s: must not run setuid or setgid", programname);
>	    exit(1);
>	}
>where is the harm in subsequently using access(2) to test for permission to
>read or write a file?

None.  But the code above may prove harmful:

>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?

Possibly not.  Certainly I cannot think of any offhand.  But if this
program might be run from another program that *is* setuid, the code
above will print an error and stop: in 4BSD, at least, exec() does
not touch the IDs if the program being exec'ed is not set-ID.  So
some *other* set-ID program may cause this one to fail.

(Of course, each set-ID program can always do

	setgid(getegid()); setuid(geteuid());

before attempting to run other programs, but few do.  Then again,
there are few set-ID programs that run other programs....)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris