riddle@woton.UUCP (Prentiss Riddle ) (12/01/87)
A colleague of mine was tinkering with a program that runs in setuid
mode when she ran into the following little puzzle:
Why is it that in SVR2.1 (and maybe in other Unixes too) the access(2)
function uses the real user ID and group ID instead of the effective
ones?
The access(2) call is supposed to determine the accessibility of a
file: that is, given a path name and a "mode" bit pattern, it returns 0
if you have the specified access permissions for the specified file.
Since your ability to actually read, write or execute a file will
depend on your effective user and group IDs, it seems logical to me
that access(2) should use them as well, but for some reason it uses the
real IDs instead.
Of course, it wouldn't be hard to use stat(2) to write a substitute
routine called "eaccess()" which do the same thing using the effective
IDs, but that leaves the nagging question: is there a good reason for
access(2) to behave as it does?
Send short, obvious answers to me and I'll summarize; post long,
wizardly answers directly to the net. Thanks.
--- Prentiss Riddle ("Aprendiz de todo, maestro de nada.")
--- Opinions expressed are not necessarily those of Shriners Burns Institute.
--- riddle@woton.UUCP {ihnp4,harvard}!ut-sally!im4u!woton!riddlejohn@frog.UUCP (12/04/87)
In article <957@woton.UUCP>, riddle@woton.UUCP (Prentiss Riddle ) writes: > A colleague of mine was tinkering with a program that runs in setuid > mode when she ran into the following little puzzle: > Why is it that in SVR2.1 (and maybe in other Unixes too) the access(2) > function uses the real user ID and group ID instead of the effective ones? > ...Of course, it wouldn't be hard to use stat(2) to write a substitute > routine called "eaccess()" which do the same thing using the effective > IDs, but that leaves the nagging question: is there a good reason for > access(2) to behave as it does? The short answer is that access() has always done that so that setuid-root programs can (try to) determine if you deserve access to a file (which root will, of course, be granted). The problem with an eaccess() routine (and with access() as well, really) is that there isn't any guarantee that, between the time that you check for permission to use a file and the time you actually hammer it, the access modes won't change so that you can't (shouldn't) be allowed to hammer the file. Since eaccess() tells you little, if anything, that you won't learn by actually DOING the operation and staring at errno when it fails, it seems to me that you might as well do it. access() is intended to let superuser programs restrain their might when needed :-). -- John Woods, Charles River Data Systems, Framingham MA, (617) 626-1101 ...!decvax!frog!john, ...!mit-eddie!jfw, jfw@eddie.mit.edu "Cutting the space budget really restores my faith in humanity. It eliminates dreams, goals, and ideals and lets us get straight to the business of hate, debauchery, and self-annihilation." -- Johnny Hart
steve@nuchat.UUCP (Steve Nuchia) (12/15/87)
In article <957@woton.UUCP>, riddle@woton.UUCP (Prentiss Riddle ) writes: > Why is it that in SVR2.1 (and maybe in other Unixes too) the access(2) > function uses the real user ID and group ID instead of the effective > ones? So that setuid programs can test the access permissions of the real user. > Of course, it wouldn't be hard to use stat(2) to write a substitute > routine called "eaccess()" which do the same thing using the effective You can use open or creat to test the efective user's permissions. Access was added so that priveledged programs could check the invoking user's permissions without using a stat kludge. -- Steve Nuchia | [...] but the machine would probably be allowed no mercy. uunet!nuchat!steve | In other words then, if a machine is expected to be (713) 334 6720 | infallible, it cannot be intelligent. - Alan Turing, 1947