Xref: utzoo comp.lang.c:8256 comp.unix.questions:6103 comp.unix.wizards:7141
Path: utzoo!mnetor!uunet!oddjob!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.lang.c,comp.unix.questions,comp.unix.wizards
Subject: Re: [braindamaged?] use of access(2)
Message-ID: <10693@mimsy.UUCP>
Date: 17 Mar 88 10:47:03 GMT
References: <59@vsi.UUCP> <1056@stratus.UUCP> <70@vsi.UUCP> <305@wsccs.UUCP> <311@dcc1.UUCP>
Distribution: comp
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 29
Keywords: access(2), permissions, setuid/setgid

In article <311@dcc1.UUCP> douglas@dcc1.UUCP (Douglas B. Jones) writes:
>There has been some talk about the access(2) only working on the real
>uid/gid pair. Two alternate possibilites:
>
>1) have a saccess(2) which will check against setuid/setgid ....
>2) have another routine, call it faccess(2) ...
>
>	ret = faccess(file_path,uid,gid);

The whole concept of an `access' system call is a bit goofy, because
it does not account for external events.  Consider, e.g.,

time	/* prog1 */			time	/* prog2 */
t=0	compute();			t=1	status = access(path,...);
t=2	mv(path, newname);		t=3	if (status == OK)
							operation(path);

prog2 has carefully verified the operation before performing it, yet
it goes awry anyway.  Since access() exists for `security' purposes,
but does not fulfill them, it should be reconsidered and probably
removed entirely.

Now, if you want a 99% solution for non-secure programs, that is
another matter entirely....  In most cases it is best to attempt the
operation anyway, and see whether it worked, but a 99% `test this out
now' call could be useful.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris