Xref: utzoo comp.lang.c:8561 comp.unix.questions:6262 comp.unix.wizards:7380
Path: utzoo!mnetor!uunet!husc6!think!bloom-beacon!tut.cis.ohio-state.edu!ut-sally!utah-cs!utah-gr!uplherc!sp7040!obie!wsccs!terry
From: terry@wsccs.UUCP (terry)
Newsgroups: comp.lang.c,comp.unix.questions,comp.unix.wizards
Subject: Re: [braindamaged?] use of access(2) -- long note
Message-ID: <368@wsccs.UUCP>
Date: 24 Mar 88 04:13:18 GMT
References: <59@vsi.UUCP> <1056@stratus.UUCP> <70@vsi.UUCP> <305@wsccs.UUCP> <393@vsi.UUCP>
Distribution: comp
Lines: 108
Keywords: access(2), permissions, setuid/setgid
Summary: IMHO...

Steven, the access() function is supposed to check using the real user and
group ID's.  This makes it do what it is documented as doing, ie: finding
out if you have access, NOT if who you are effectively has access.

In article <305@wsccs.UUCP>, I write:
> 
> 	No, it does what it's supposed to.

In article <393@vsi.UUCP>, you reply:
> 
> 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 process by which an exec() works is exactly that by which my example works;
your euid and egid become your uid and gid.

> The difficulty is because the shell probably uses access(2) to see if
> /usr/acct/bin/report is executable

It does.  Isn't that what it's supposed to do?

> -- this is simply incorrect in a setuid/setgid environment.

How so?  It prevents you from making a costly mistake even more costly.  If you
have a hole in a program you write, access() not operating in the fashion you
have suggested it "should" operate would act to minimize any damage by
restricting what it was possible to bash and what it was possible to bash it
with.  I don't admit an IFS problem with my method.  There are ways to avoid it,
most notably with "putenv()", which is available on a lot of systems.

> 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.

If you are talking a shell script, the reason I believe it works in Berklix is
that Berklix runs another shell in order to interpret shell scripts... SysV.3
does not (at least on the systems I work on).  This has resulted in a number
of technical support calls as people installed older versions of our software
on their new SysV.3 ...it seems we used to use "exec" to avoid running an
additional process.  The shell scripts break, as exec is not allowed from
within a shell script (I can document the boxes this is true on).  The one
exception would be a user running a shell other than sh which forced the use
of the Bourne Shell (a ':' as the first character in the file).

> > 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 have.  It's non-applicable.  I seem to remember the smell of roasting ME
last time I used the word "Obviously".

> Anybody else think I blew it on the entire posting?

I didn't flame your entire posting.  I could have nit-picked.  As you pointed
out in your return salvo, you were using access incorrectly.

The reason it is REAL uid/gid is to allow you to run suid/sgid programs which
allow you access to functions based on who you really are when the functions
themselves are normally priveledged.  This is useful if you are writing system
software... for instance, if mknod() had to be done by root, as the only user
capable of modifying a file system, as is the case in a number of recent UNIX
implimentations.  Your "mkdir" command would have to be SUID root, but still be
able to tell who actually ran it.

I think the primary use would be in a systems-software situation, not a user
software-that-needs-access.  I agree that if there was a great deal of demand
for determination of access for euid programs, it would be a good idea to
impliment another function ...I think eaccess() would be a better name, tho.


| Terry Lambert           UUCP: ...{ decvax, ihnp4 }                          |
| @ Century Software          : ...utah-cs!uplherc!sp7040!obie!wsccs!terry    |
| SLC, Utah                                                                   |
|                   These opinions are not my companies, but if you find them |
|                   useful, send a $20.00 donation to Brisbane Australia...   |
| 'There are monkey boys in the facility.  Do not be alarmed; you are secure' |