[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