[OpenAFS] Re: Ideas for finer grain set acl controls

[Andrew Deason]

On Sat, 31 Oct 2009 20:29:53 +0100
Sergio Gelato <Sergio.Gelato@astro.su.se> wrote:

> * Jeffrey Altman [2009-10-30 13:20:12 -0400]:
> > To address the use case properly there needs to be the ability to
> > apply additional sets of ACLs controlled entirely by the
> > administrator. Positive ACLs that give privileges that cannot be
> > restricted and negative ACLs that restrict privileges that cannot
> > be granted.  These would have to be enforced by the file server at
> > access time.  This ensures that changes in group membership do not
> > bypass the administrator set permissions.
> 
> Even then, the devil lies in the details. I see no difficulty in
> having such additional ACLs work globally or with volume granularity,
> and this would be enough to express simple policies such as "no wida
> rights anywhere in the cell for system:anyuser"; but if one were to
> set such an additional ACL only on a user's public_html directory,
> what is there to keep the user from renaming directories? 

Relaxing the retrictions on a subset of volume data is impossible to do
sensibly, unless we do something like storing the paths (as strings)
from the volume root for directories we don't enforce. That sounds like
a scalability nightmare to me.

Personally, I think it's reasonable for this to be at volume
granularity. If you relax restricitons on a vnode inside the volume,
that vnode could go anywhere. So, what you're really saying is "you get
1 directory where these restrictions don't matter, wherever that
directory is". That doesn't seem very useful.

To solve the specific problem you mentioned, I would say you just give
each user a separate volume for web space, and change the volume-level
ACL for that volume. In the particular case of webspace, that also has
the benefit of being able to mount the user web volumes somewhere more
logical in the hierarchy, and ensures you are actually accessing their
web volume. (I.e. you mount the volume at
/afs/localcell/user/$user/public_html, and
/afs/localcell/common/web/user/$user, or something like that)

-- 
Andrew Deason
adeason@sinenomine.net