[OpenAFS] Re: Supergroups and ACL inheritance

[Andrew Deason]

On Thu, 24 Feb 2011 18:01:10 -0700
Thomas Smith <theitsmith@gmail.com> 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
adeason@sinenomine.net