Xref: utzoo comp.lang.c:7757 comp.unix.questions:5923 comp.unix.wizards:6806
Path: utzoo!mnetor!uunet!vsi!friedl
From: friedl@vsi.UUCP (Stephen J. Friedl)
Newsgroups: comp.lang.c,comp.unix.questions,comp.unix.wizards
Subject: Re: [braindamaged?] use of access(2) -- long note
Message-ID: <70@vsi.UUCP>
Date: 2 Mar 88 11:43:17 GMT
References: <59@vsi.UUCP> <1056@stratus.UUCP>
Distribution: comp
Organization: V-Systems -- Santa Ana, CA
Lines: 49
Keywords: access(2), permissions, setuid/setgid
Summary: It's not me, it is *other* software using access

In article <1056@stratus.UUCP>, strick@stratus.UUCP (henry strickland) writes:
> In article <59@vsi.UUCP> friedl@vsi.UUCP (Stephen J. Friedl) writes:
> >[....]
> >      Access(2) should almost never be used.  It does what
> >stat(2) does except it uses the REAL userid and not the EFFECTIVE
> >userid like every other system call uses.  It is designed for use
> >by setuid/setgid programs to verify the permissions of the
> >"underlying" user.
> 
> I also feel that access() should almost never be used, but for
> quite different reasons.
> 
> First (and I think you realized it) you're not using access()
> for what it was intended.  
>
> [lots more comments deleted]

     I guess I gave an unclear posting.  *I* know how access(2)
works and how to do the permissions checking in the right way.  A
version of access (I call it accfile) does the same kind of check-
ing but with the "proper" uid/gid.

     My lament is that *other* software (/bin/sh, test(1), temp-
nam(3), the Informix sacego report processor, etc.) does it wrong
and it keeps me from doing it right.  For example, the shell's
$PATH search mechanism means that I have to keep the project bin/
directory open to everybody because the shell won't find my com-
mands otherwise.

     I have just found out that mkdir(1) on System V doesn't work
right either.  It runs setuid root (only root may mknod a direc-
tory) and it uses access to find out if the underlying user has
permission to do this.  I guess they miss the case where the ef-
fective group has permission but the real+effective user and real
group do not.  Yet another case of the kernel doing what I tell
it rather than what I want.

     Wouldn't it make sense to (A) provide a "accfile()"
syscall/routine that does access(2) with real ids and (B) put a
note on the access manual page saying "you probably don't want to
use this function." Perhaps provide a version of access that is
passed the user/group ids to be checking against?  Then it could
fit all the needs.

     Steve
-- 
Life : Stephen J. Friedl @ V-Systems, Inc./Santa Ana, CA   *Hi Mom*
CSNet: friedl%vsi.uucp@kent.edu  ARPA: friedl%vsi.uucp@uunet.uu.net
uucp : {kentvax, uunet, attmail, ihnp4!amdcad!uport}!vsi!friedl