[braindamaged?] use of access(2)
Chris Torek
chris at trantor.umd.edu
Wed Mar 2 14:16:51 AEST 1988
>In article <59 at vsi.UUCP> friedl at vsi.UUCP (Stephen J. Friedl) writes:
>> Access(2) should almost never be used.
In article <1056 at stratus.UUCP> strick at stratus.UUCP (henry strickland) writes:
>Like you explained, it was intended for programs such as "mail"
>to make sure the REAL user/group has permission
>to write/read stuff from where the user has said to write/read
>the stuff from.
>
>*** There are security holes in this approach. ***
This is true (the hole is a `race' hole: get a set-ID program to
decide something is secure, then change the operation while it is
not looking, just before it actually does it). But:
>The correct thing to do is
> { setuid(getuid()) ; getgid(getgid()) }
>before doing the i/o. This allows the real unix permission
>checking to do its job. This is the safe approach.
This approach may be (often is) insufficient. In 4.2 and 4.3 BSD,
you can do this cleanly and correctly, by swapping real and effective
IDs; the swap may be performed any number of times, unlike setgid/setuid,
which is irreversable (except under peculiar conditions in SysV).
>If you later will need the capabilities of your effective
>uid and gid, fork a child to do the job, and wait for it
>to die. Then continue.
This is horribly inefficient, and can be overly difficult. It is,
however, portable.
>I think that access() is a late addition to unix (when did it come?).
It has been around since at least V7, I think.
--
In-Real-Life: Chris Torek, Univ of MD Computer Science, +1 301 454 7163
(still on trantor.umd.edu because mimsy is not yet re-news-networked)
Domain: chris at mimsy.umd.edu Path: ...!uunet!mimsy!chris
More information about the Comp.unix.questions
mailing list