Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cwjcc!tut.cis.ohio-state.edu!ucbvax!hplabs!pyramid!csg From: csg@pyramid.pyramid.com (Carl S. Gutekunst) Newsgroups: comp.sys.pyramid Subject: Re: OSx4.4 att universe security / group restrictions Keywords: osx4.4 groups Message-ID: <58511@pyramid.pyramid.com> Date: 9 Feb 89 19:23:04 GMT References: <5328@brspyr1.BRS.Com> Organization: Pyramid Technology Corp., Mountain View, CA Lines: 41 In article <5328@brspyr1.BRS.Com> tim@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 % 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.