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

1: unix user permissions: what is aolserver smoking?

Posted by Jonathan Ellis on 02/20/01 05:39 AM

If I have a user jon who owns a directory, but give it nsadmin as group, with full permissions for both owner and group, e.g.,

ls -ld foo
drwxrwx---    2 jon  nsadmin      4096 Feb 19 21:09 foo

then my tcl ns_schedule_proc's can't read the directory:

couldn't read directory "/home/foo": permission denied
    while executing
"glob {~foo/*.tar.gz}"
    (procedure "move_foo" line 2)
    invoked from within
"move_foo"

But, when I su to nsadmin and run glob {~foo/*.tar.gz} from the tcl shell, it works fine. What the #@$%@#$%@#$%???

When I chown the directory to nsadmin, the scheduled proc works fine. Just not when owned by another user. Is this a "feature?" Pretty damn annoying if you ask me. If unix tells you you can read it, you should #$@%@#$% well read it, nsd!

(Yes, I'm peeved -- this has wasted far more time than it should have.)

2: Response to unix user permissions: what is aolserver smoking? (response to 1)

Posted by Don Baccus on 02/20/01 04:54 PM

I don't suppose you'd consider telling us how you're running nsd, i.e. the -u and -g values you use to establish the user and group it runs as?

3: Response to unix user permissions: what is aolserver smoking? (response to 1)

Posted by Jonathan Ellis on 02/20/01 07:17 PM

nsd running as -u nsadmin -g web

Like I said, when I su'd to nsadmin I was able to access it fine, so nsd is doing something fishy.

I also tried giving the directory group foo and then adding nsadmin to that in /etc/group. Also worked when I su'd; also didn't work when nsd ran the proc.

Just now I tried changing it to jon:web, and nsd likes that too. I can see how that could make a twisted sort of sense, but it still strikes me as very nonstandard.

4: Response to unix user permissions: what is aolserver smoking? (response to 1)

Posted by Malachi Kenney on 02/21/01 08:57 AM

drwxrwx--- 2 jon nsadmin
nsd running as -u nsadmin -g web

Look at these two facts again. Just a suggestion.

5: Response to unix user permissions: what is aolserver smoking? (response to 1)

Posted by Jonathan Ellis on 02/21/01 04:36 PM

nsadmin's default group is nsadmin, as would be expected on a RH system. My point is that nsd is ignoring what unix says its permissions are in favor of some sick twisted "I'm running as web and that's the ONLY group I will allow myself to look at."

6: Response to unix user permissions: what is aolserver smoking? (response to 1)

Posted by Lamar Owen on 02/21/01 05:27 PM

nsd is doing things just exactly as you tell it to do. That is standard Unix daemon behaviour, BTW: if I run the PostgreSQL postmaster, for instance, as user postgres group database, and try to access a file owned by lowen.postgres, it will fail, as the user.group pair doesn't match in either respect. Either start nsd with -g nsadmin or change the group ownership of the file in question to web.

When you specify the group to run, why should nsd access with any other group id? How does it know that you don't want to restrict the group for security's sake?

This is standard Unix user.group behaviour. Nothing new.

7: Response to unix user permissions: what is aolserver smoking? (response to 1)

Posted by Jonathan Ellis on 02/21/01 05:42 PM

Okay, thanks for clearing that up. My reasoning was, if I su to someone, even if I belong to some totally different default group, when I try to access the directory belonging to group nsadmin, unix thinks, "I see this line nsadmin:x:502:jon in /etc/group, so I will let him in." I didn't know that doesn't apply to daemons.

8: Response to unix user permissions: what is aolserver smoking? (response to 1)

Posted by Lamar Owen on 02/21/01 06:56 PM

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?

9: Response to unix user permissions: what is aolserver smoking? (response to 1)

Posted by Jonathan Ellis on 02/21/01 07:16 PM

Thanks again. Too bad I installed RH 6.2 on my Sparcstation (so much of the software out there today is really meant for linux; postgres in particular IIRC did NOT want to work under solaris/sparc4m), but I believe you. :)