[braindamaged?] use of access(2) -- long note

[Stephen J. Friedl]

In article <305 at wsccs.UUCP>, terry at wsccs.UUCP (terry) writes:
> Obviously, you have not heard of the link function,
> which allows you to link a file to another file.

Saying thinks like "obviously you have not heard of xxx" only
irritates people, especially when they have indeed heard of it as
I have.  Surely you can find a more constructive/pleasant way of
offering your $.02.

> > (I write):
> >      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.
> 
> 	No, it does what it's supposed to.

No, it doesn't.  If I have the following directories:

   3 drwxr-x---   4 acct  acct   1234 Feb 10 12:24 /usr/acct/
  20 drwxrwx---   1 acct  acct  10000 Feb 10 13:55 /usr/acct/datadir/
   5 drwxr-x---   4 acct  acct   2352 Feb 10 13:55 /usr/acct/bin/
  20 -rwx--x---   1 acct  acct  10000 Feb 10 13:55 /usr/acct/bin/report

Now, I have a front-end (say, "runacct") that makes me:

	uid  = friedl 
	euid = friedl
	gid  = staff
	egid = acct   <---- setgid!

This program calls up a menu and runs the entire system with an
egid of "acct".  If my $PATH includes /usr/acct/bin and a script
(probably also run from /usr/acct/bin) with the line

	report 1/88

the shell will not run my command, but

	/usr/acct/bin/report 1/88

works fine.  In the first case, the exec(2) will work -- I *do*
have permission to run the program.  The difficulty is because
the shell probably uses access(2) to see if /usr/acct/bin/report
is executable -- this is simply incorrect in a setuid/setgid
environment.

Mkdir is broken as well.  If I have a script -- running in the
same directory structure as above with the same permissions,
should:

	mkdir /usr/acct/datadir/disk.01

make the directory?  I say yes, mkdir(1) says no.  This probably
works in SVR3 (and 4.3BSD?) because mkdir(2) magically appeared
augmenting mknod(2).

> system( "/bin/sh -c /bin/mkdir /bin/foo");
> 
> [...]  Note that I forced the path on the mkdir
> command so the user could not have his own mkdir in his
> path before the /bin one, thereby preventing [...].
> 
"Obviously" you have not heard of the $IFS fraud :-).

I contend that access(2) is improperly used in the overwhelming
majority of cases.  If you want to find out if the current user
has permission to access a file, stat(2) or open(2) it, but don't
use access(2).  If you (generic programmer "you") use access but
don't understand the objections to it I think there is a good
chance that you don't fully understand access either.

> >      Wouldn't it make sense to (A) provide a "accfile()"
> > syscall/routine that does access(2) with real ids...
> 
> 	Or you could use the method above... gee, now why should
> you complicate the library more again?

OK, I blew it in this paragraph.  I wanted to say that accfile()
should use the EFFECTIVE uid/gid rather than the REAL uid/gid
as I so incorrectly said.  With that change, the rest of the
posting stands and I want accfile() very much.

Anybody else think I blew it on the entire posting?

-- 
Steve Friedl, KA8CMY     ARPA/UUNET/CSNet: friedl at vsi.com      *Hi Mom*
uucp email : { kentvax, uunet, attmail, ihnp4!amdcad!uport }!vsi!friedl
"Too bad we judge others by their actions and ourselves by our motives"