On Thu, 24 Feb 2011 18:01:10 -0700 Thomas Smith <[email protected]> wrote:
> Groups: > * group0 - The primary group for office location "group0". > * group0:admins - Office administrations for "group0". I assume you added group0:admins to group0? You don't say that, but you mention supergroups... but it doesn't seem to be too relevant to this. A 'supergroup' is when you add a group as a member of another group; I'm not sure if that's what you meant. You do that by running something like 'pts addu group0:admins group0'. You also probably don't want to name the groups that way. The colon in group names is a special delimeter, indicating that group0:admins is owned by group0 (iirc, pts will not let you create that group unless you specify it as owned by group0). So, members of group0 will be able to add and remove members to/from group0:admins. That doesn't seem like what you want. You could create a group called group0 and a group called group0.admins (or groups called group0.members and group0.admins), and have the admins 'own' the non-admin group. You can specify ownership via 'pts createg -owner' or 'pts chown'. > Directory Structure: > * /afs/domain/Offices/Group0/ with group permissions: > * * group0 rlidwk > * /afs/domain/Offices/Group0/Admins/ with group permissions: > * * group0:admins rlidwk > * * -neg group0 rlidwk You don't want negative permissions there. I've found, at least for me, negative permissions are rarely what you want to do. I'm assuming you want 'group0' people to be able to put stuff all over the Group0/ directory, but only want group0:admins to have access to the 'Admins' directory? Depending on how secure/strict you want this to be, I'd be a little wary of organizing the directories like this. No matter what you do, you will be allowing 'group0' members to do something like this: $ mv Admins .someotherdir $ mkdir Admins Since group0 have rights to move stuff around. And now 'Admins' will have permissions "group0 rlidwk". If an 'admin' doesn't notice and drops some file in there, all members of 'group0' will be able to access it. You may be better served by a pair of directories: Group0/Members and Group0/Admins. Then just grant 'group0 l' on Group0, and give rlidwk to group0 in Group0/Members, and rlidwk to group0:admins in Group0/Admins. Or something like that. But if you trust 'group0' non-admins to not be nasty, it doesn't really matter. > Setting it up like this, group0:admins are not able to access the > Admins directory. Yes, negative permissions are applied after the positive ones. > I also tried just removing group0 (rather than adding the negative > permissions) but that didn't work either--in fact, doing this allows > group0 to gain access to that directory. You should double-check this. If a directory has the permissions group0:admins rlidwk and _only_ those permissions, anyone that is not a member of group0:admins will not be able to do anything in that directory; the permissions on the parent directories do not matter. If you see otherwise, please report who you're accessing as, and the group membership of the relevant groups. Of course, if the accessing user is a member of group0, they should be able to just add themselves to group0:admins in your example. But they shouldn't have those rights without doing so. > I've looked for examples of how to setup supergroups as well as how to > work with AFS's ACL inheritance and haven't found much. We surprisingly don't mention supergroups in any manpages except for 'pts membership'. We should add something in 'pts adduser' and 'pts removeuser', probably. But they should be rather intuitive; I don't think you're getting tripped up on supergroups. "ACL inheritence" doesn't happen much in AFS, if I'm understanding that term correctly. That is, the permissions you have or not have in parent directories don't really affect you in lower directories (except inasmuch as you can actually reach the lower directories). There are a few instances where you implicitly gain certain rights (if you are the owner of the root of a volume, if you are the owner of a file in 'dropbox' scenarios), but they are more special-case scenarios. Some information on using groups and their relation to owners and such is discussed in the Admin Guide, here: <http://docs.openafs.org/AdminGuide/ch14s05.html> and probably some other places. -- Andrew Deason [email protected] _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
