On Thu, Feb 24, 2011 at 10:11 PM, Andrew Deason <[email protected]>wrote:
> 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'. > When I think of "supergroups" I think of "nested groups"--simply having groups within a group. * http://docs.openafs.org/Reference/1/pts_creategroup.html The command that I use to create such groups is this: * pts creategroup -name group0:admins -owner group0 It seemed like a more logical way to organize group memberships and established relationships between groups and sub-groups. But maybe my understanding on this topic is a little off. > 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. > Correct. This is not what I want. So I will need to change this. > 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'. > This is a good idea, but we have a tightly controlled user access policy, so only certain people have the authority to approve changes to user accounts. However, I do like the the naming scheme you suggested. > > 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? > Your assumption is correct. What purpose does negative permissions serve if not to remove permissions inherited from a higher level? > 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. > I just tested this from a Windows computer using standard Windows commands (ren, copy, xcopy, and renaming the directories through Explorer) and all generated an Access Denied. Is there another way I should try this? I would just like to understand this scenario a bit more--my current directory structure will need some reworking given what you're suggesting. "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. > Here is my understanding of ACL inheritance in AFS. /afs/domain: system:authuser l /afs/domain/Offices/group0: group0 rlidwk (Note that group0 is a volume mount point.) In this situation, "system:authuser l" propigates /afs/domain's directory structure--that is, every new directory will have the permissions "system:authuser l". However, this propagation doesn't cross volume boundaries. So, the "system:authuser l" permission isn't applied to Offices/group0 by default. As such, only the group "group0" will have any access to that. In a similar vein, "group0 rlidwk" will be applied to all directories created within the Offices/group0 volume. I'm new to AFS and still learning, but this is my current understanding. Is my understanding of ACL inheritance correct? Thanks for your input Andrew. I will end up changing around a couple of things as a result of your feedback.
