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?