tim@brspyr1.BRS.Com (Tim Northrup) (01/27/89)
*********** I sent this out a couple of weeks ago (or so I thought), but got zero response, which is very unlike this newsgroup, so I am sending it again. *********** We have a job/printer queue package that uses g+s along with a special group ID which is used on all control files. 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 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. Is this the way it is supposed to work in the att universe? Not only does it affect our queue package, but mail programs as well (and probably others). Is this specific to OSx4.4? Any help would be appreciated. -- Tim -- Tim Northrup +------------------------------------------+ +---------------------------------+ GEnie: T.Northrup | UUCP: uunet!steinmetz!brspyr1!tim | Air Warrior: "Duke" | ARPA: tim@brspyr1.BRS.Com +------------------------------------------+
csg@pyramid.pyramid.com (Carl S. Gutekunst) (02/10/89)
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 <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>