Forum OpenACS Q&A: Response to unix user permissions: what is aolserver smoking?

NOTE: I formatted this as HTML in the web version. The e-mailed version may be broken.....

Ok, I have here a test for you to see that what's happening is indeed the 'proper' behavior (for various degress of 'proper' 😊). Here's the test directory ls -l:

[root@utility test]# ls -l
total 20
-rwsrwsrwx 1 aolserve lowen 9528 Feb 21 12:20 cat
-r-sr-sr-x 1 aolserve lowen 9264 Feb 21 12:20 id
-rw-rw---- 1 lowen aolserve 23 Feb 21 11:52 testfile1
-rw-rw---- 1 aolserve lowen 23 Feb 21 11:52 testfile2
drwxrwx--- 2 lowen aolserve 4096 Feb 21 11:52 testing
drwxrwx--- 2 aolserve lowen 4096 Feb 21 11:52 testing2
[root@utility test]#cat testfile1
testing suid/sgid junk
[root@utility test]

Testfile1 and testfile2 are identical.

Notice that I'm running as root, and the copy of /bin/cat in this directory is suid aolserver, sgid lowen. The uid aolserve that ls is reporting is actually the 8 char truncation of the username aolserver, and is not a member of the group lowen. So, when I execute './cat testfile1' in this dir (as _root_, no less), I get this result:

[root@utility test]# ./cat testfile1
./cat: testfile1: Permission denied

Ok, let's do another test. The 'id' command will show you all sorts of stuff about the current run user. So, I make a copy of id into the current directory, and make it suid/guid (mode 6555), owner aolserver.lowen. Running ./id gives me:

[root@utility test]# ./id
uid=0(root) gid=0(root) euid=501(aolserver) egid=500(lowen) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) [root@utility test]#

Notice the 'euid' and 'egid' lines. I cannot use su to give me the combination of a user and group that are mutually exclusive, unfortunately, so I can't compare.

Now, let's make aolserver a member of lowen and see if executing './cat testfile1' can access the file now:

[root@utility test]# su aolserver
[aolserver@utility test]$ id
uid=501(aolserver) gid=501(aolserver) groups=501(aolserver),500(lowen) [aolserver@utility test]$ cat testfile1
testing suid/sgid junk
[aolserver@utility test]$ ./cat testfile1
testing suid/sgid junk
[aolserver@utility test]$exit
exit
[root@utility test]# ./cat testfile1
./cat: testfile1: Permission denied
[root@utility test]#

Hmmm. Let's try accessing testfile2, which has the same uid/gid owner as cat does:

[root@utility test]# ./cat testfile2
testing suid/sgid junk
[root@utility test]#

Yep, it works properly for exact matches.

Are you confused now? 😊 Effective GID and UID don't follow the group membership, but only use the effective gid in following permissions, it appears. And, unless I cam badly mistaken, nsd uses the effective uid and gid settings.

But it's not nsd that's broken -- it's Linux/glibc, if you want to call the behavior 'broken'. Can someone with some other Unix test the above and see what happens?