[OpenAFS] Re: Supergroups and ACL inheritance

[Andrew Deason]

On Fri, 25 Feb 2011 14:27:55 -0700
Thomas Smith <theitsmith@gmail.com> wrote:

> 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.

I tend to think of groups with a colon in them as more... unofficial, or
per-user/per-group. That is, they are "convenience" groups created by a
user or group, and not something to be messed with by administrators, or
as part of official policy ("the administrators of group0 go in group
group0.admins"). Instead, they are groups like adeason:friends, for
"adeason's friends", that's only really used by adeason, and only
adeason controls it.

system: groups are a bit of an exception, since those are special
groups. And that's not the only way to use them, but that's just how I
intuitively think of them. I tend to stay away from prefixed groups when
I'm an administrator setting up groups for another department or
something.

> What purpose does negative permissions serve if not to remove
> permissions inherited from a higher level?

Say I want to let everyone in 'staff' access some new tool I wrote in
~adeason/code. But I don't want to let user mmeffie (who is in 'staff')
access it, because he complains about the way I drink whiskey.

So I can:

fs sa ~adeason/code staff read
fs sa ~adeason/code mmeffie all -neg

That way, everyone in 'staff' always had read access, even if more
people are added to 'staff' later. But mmeffie can never read it.

> > 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.

I'm not really familiar with Windows commands... I would assume they are
trying to access some directory metadata, and are failing on that, but I
don't really know. I don't know if someone more familiar with Windows
can shed some light on that, but a 'mv' in unixy systems will work.

> 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".

That is correct. In other systems, I've heard "ACL inheritence" to mean
that permissions granted in higher directories somehow interact with the
permissions in lower directories. Meaning, if you grant 'system:authuser
l', all subdirectories also gain that permission implicitly. In AFS, the
_default_ ACL for new directories is the same as the parent directory,
but after the directory is created, the parent directory permissions
have no impact on the subdirectories.

> However, this propagation doesn't cross volume boundaries. So, the
> "system:authuser l" permission isn't applied to Offices/group0 by
> default.

Yes, this is due to how mountpoints are very different than directories.
You can think of this as an additional step that "mkdir" does; since you
don't create mountpoints with "mkdir", it doesn't happen to mountpoints.

A more accurate way to think about it is to realize that the root
directory of a volume does not have a parent directory in the usual
sense. Since you can create many mountpoints to the same volume from
anywhere in /afs (and even from different cells), the alleged "parent
directory" may be different, depending on which mountpoint you are
arriving from.

Also realize that the root directory of a volume (and its ACL) is
created when you create the volume, not when you create the mountpoint.
So, at that time, it certainly has no 'parent directory' to get an ACL
from.

> 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?

Yes, as long as you realize that it's only for newly-created
directories. After you make a directory, it is not tied to the ACLs of
anything else.

-- 
Andrew Deason
adeason@sinenomine.net