[OpenAFS-devel] Re: Methods of Restricting AFS3 ACL rights

Jeffrey Hutzelman jhutz@cmu.edu
Sun, 17 Jan 2010 23:39:48 -0500


--On Sunday, January 17, 2010 01:43:53 PM -0600 Andrew Deason 
<adeason@sinenomine.net> wrote:

> On Sat, 16 Jan 2010 05:10:21 +0000
> Adam Megacz <adam@megacz.com> wrote:
>
>>
>> Andrew Deason <adeason@sinenomine.net> writes:
>> > The explanation for the various methods now exists as an Internet
>> > Draft, and can be found here:
>>
>> AFAIK, a volume is the unit of space management, while a directory is
>> the unit of access management. [*]
>
> Currently, yes, in a way you could say that. The difference here is that
> the described access controls are set by an administrator, not typically
> by the users modifying the volume data.

Precisely.  You can think of a volume as a unit of space management, but 
that's really the wrong generalization.  A volume is the unit of storage 
_administration_, for a variety of operations.  For the most part, 
administrators do/should act on volumes as a whole, not on the data 
contained within them.  We create, move, and delete entire volumes, set 
quotas for entire volumes, and even grant a certain amount of access on 
volumes, by setting their owners.  It is natural to want to have more 
control over access rights at the volume level, including both more 
flexibility in setting rights to be granted on every volume and in 
restricting what rights can be granted on a volume's contents.


As for the argument for something more complex than "administrators"; I 
think it misses the point.  Ordinary ACL's _are_ the flexible mechanism 
that can be used by anyone.  What we're talking about here is a mechanism 
that can be used by a cell's administrators to enforce policy.  It's 
appropriate to do that on a per-volume level, and to restrict the operation 
to administrators, just as we do for other policy mechanisms such as quotas.

You could build into AFS the complexity of allowing anyone to be given the 
ability to set that policy, and allowing anyone to be given the ability to 
set policy about who can set that policy, and so on ad infinitum.  But what 
most sites do instead is either only have one level of administrator, or 
have some sort of privilege delegation service which understands that 
site's meta-policy (and meta-meta-policy, and so on), and exercises 
administrative level power on the request of authorized users.

What we're talking about here won't create or eliminate the need for such a 
service, at sites which have sufficiently complex policy to need one.  What 
it does do is create a new tool to allow access control policy to be 
expressed to AFS, so that it can be properly enforced.


-- Jeff