OSx4.4 att universe security / group restrictions

[Carl S. Gutekunst]

In article <5328 at brspyr1.BRS.Com> tim at brspyr1.BRS.Com (Tim Northrup) writes:
>I sent this out a couple of weeks ago (or so I thought), but got zero
>response....

Hey, I been *busy.* Besides, this problem required some actual work. :-)

>If a user is in a directory which does not allow "other" groups access and
>is owned by the same group as a user (but different group than that used on
>the [sgid] program), under the att universe the program is denied access to
>the directory. Under the ucb universe, the real group ID allows for access
>to the directory as it should.

To recreate the problem, I made local copies of /.ucbbin/cat and /.attbin/cat,
made them sgid, and changed their group to "other." Then I created a little
file called "foo," set it to be owned by root, with my own group permissions,
and made it readable only to owner and group.

	% ls -lg
	-rwxr-sr-x  1 root     other       28672 Feb  8 01:59 attcat
	-rw-rw----  1 root     comm           18 Feb  8 02:13 foo
	-rwxr-sr-x  1 root     other       30720 Feb  8 01:59 ucbcat
	% ucbcat foo
	<contents of foo>
	% attcat foo
	cat: cannot open foo

This is correct for the respective universes, and I'd argue that the System V
behavior you are unhappy with is actually more consistent. In all other cases,
it is the *effective* UID or GID that determines access permissions. Only BSD
has the exception that it will open the file based on the real GID. (Neither
will open a file when the real UID would allow it, but the effective does not.
This is why, amongst other reasons, that suid programs like UUCP insist on
their files being world readable.)

I would guess (I don't have kernel source handy to check, and Guy Harris will
correct me if I'm wrong :-)) that this is a side effect of the way BSD sets
up group membership. That is, in SVR3, you can belong to only one group at a
time. In BSD you have a whole group access list, that allows you to belong to
several groups simultaneously. 

<csg>