Xref: utzoo comp.lang.c:8193 comp.unix.questions:6073 comp.unix.wizards:7068 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: <393@vsi.UUCP> Date: 15 Mar 88 05:55:09 GMT References: <59@vsi.UUCP> <1056@stratus.UUCP> <70@vsi.UUCP> <305@wsccs.UUCP> Distribution: comp Organization: V-Systems, Inc. -- Santa Ana, CA Lines: 91 Keywords: access(2), permissions, setuid/setgid Summary: No, blame Unix, not me. In article <305@wsccs.UUCP>, terry@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@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"