Methods of Specifying Restrictions on AFS3 ACLs

Discussions have shown that preventing this is not a simple issue, and that there are a few ways to go about it, each with advantages and disadvantages. Here we will outline 3 general approaches, and show how to use them to meet certain illustrative use cases. Since the rest of this is quite long, here's a quick summary of the conclusions. We have three methods: 'method A' is the "volume-level ACL overlays" idea, 'method B' is the "volume ACL masks" idea, and 'method C' is the "volume ACL policies" idea. While none of these in themselves cover all corners of all possible use cases, we would probably implement either C by itself, or A and B together to cover a large enough majority of use cases. Of course, unless a serious problem is found, there is no reason to not implement all three. The bottom line is that I find method C to be the most flexible and the least confusing to end-users, but it is the most confusing to administrators, and it is the slowest (when changing the volume-level permissions). Using methods A+B has the opposite pros/cons. Here are the details. Each method has an explanation for what it generally is and how it works, followed by its use in a few simple use-case scenarios, followed by the pros/cons.

With this method, we maintain a single additional ACL in the volume metadata, which is applied to access checks in the volume after performing the per-directory ACL check. It can be thought of as similar to the OpenAFS fileserver's -implicit flag, but more generalized. For example, if we wanted a volume where system:backups was guaranteed to have 'rl' rights, and system:evilusers was guaranteed to not have _any_ rights, the volume-level ACL overlay would look like this:

Thus, any time an access check is done on an ACL anywhere in the volume: after we do the normal directory ACL check, we look at this volume-level ACL. If the accessing user is in system:backups, they will get rl rights, and if they are in system:evilusers, all of their rights will go away.

To prevent system:anyuser from having write access, we will need to allow specifying the 'anonymous' user in the volume-level ACL, which refers only to unauthenticated accesses. Then, you just give negative write rights to the anonymous user. The command would look something like:

For system:authuser, you cannot prevent write access with this method. It is a limitation of this approach. (Giving system:authuser negative idwka rights would revoke those rights from _all_ authenticated users, which is probably not what you want to do.)

Just grant negative idwka access to group.foo on the volume. Something like:

Members of group.foo will now not be able to write anything in the volume.

Same as above, just grant positive read rights. Something like:

Changing the volume-level rights is quick. Minimal end-administrator confusion; this is relatively simple to understand. Simpler than method C to implement.

We have no way to restrict access of special groups like system:authuser or host IP groups. To get this, we'd have to combine with method with method B or C. There is no way to override the volume-level ACL, and have an administrator force e.g. system:anyuser write access on a particular directory. Higher end-user confusion. With legacy 'fs listacl', there is no way to see that there is a volume-level ACL in play, and users may have no idea why access is failing for certain cases. Of course, releasing new tools can fix that. Performance impact is an extra O(n) ACL calculation for the volume-level ACL overlay in the critical path. But those ACLs should be small anyway.

With this method, we maintain a mapping of users to a rights mask. Any time an ACL access check is performed, if a positive ACL entry matches a user in that table, the acquires rights are masked to the rights mask in the table. For example, if we wanted to prevent users from giving away write access to system:anyuser, and prevent users from giving admin access to system:authuser, we could have a table like so:

So any time an ACL entry for system:anyuser appears, everything is treated as if the rights in that ACL entry were logically ANDed with 'rl'. So no user can gain more than 'rl' rights on a directory simply by being in system:anyuser.

Set the rights mask for them to just 'rl'. Something like:

So any time an ACL entry for system:anyuser appears in the volume, everything will act as if the rights were limited to rl.

You cannot _prevent_ access for an arbitrary group with this method, but you can make it harder to do accidentally. You can set the rights mask like so:

Which restricts any rights for group.foo on any ACL to be restricted to 'rl'. However, a user can intentionally work around this by simply placing group.foo in another group:

Since group.foo itself never apears in the ACL, the ACL mask is bypassed.

You cannot. This method cannot grant additional rights.

Changing the rights mask is quick. Runtime performance overhead in the critical path is O(1).

Not as useful for non-'special' groups. That is, it can be trivially worked around, unless you only use this for groups like system:anyuser, system:authuser, or host IP groups. No way to override the ACL masks on a particular directory, if the administrator wants to. Higher end-user confusion with legacy client tools. There's no way to see what the ACL rights are restricted to until newer client tools are deployed.

With this method, we maintain policies of who is allowed to set what ACLs in a volume. That is, unlike methods A and B, we perform additional access checks at SetACL time, not at the time when the files are accessed. We would have 4 volume-level ACLs that define what users are allowed to add positive rights ('add-positive'), remove positive rights ('remove-positive'), add negative rights ('add-negative'), and remove negative rights ('remove-negative'). For example, to allow nobody but system:powerusers to grant idwka rights to system:anyuser, we'd have a policy for system:anyuser that would look like this:

After that policy is set, any time a user not in system:powerusers tries to grant system:anyuser more than rl rights, they will get an EACCES error. This does not change the existing ACLs in the volume; an administrator will need to run an auditing tool to make sure that existing ACLs comply with the volume policy.

You would call something like this

to prevent people from giving system:anyuser write access. To ensure that existing ACLs don't permit write access, you would need to run something like

To prevent an arbitrary normal group from getting write access, things are slightly different. You would need to prevent users from taking away negative idwka rights, and then assign negative idwka rights to all directories in the volume. So, something like

Would allow users to only remove 'rl' rights from group.foo in negative ACLs. Then you would need to set negative idwka ACLs on all directories in the volume.

Prevent normal users from taking away read access from group.bar, and from granting negative read access for group.bar:

Then, grant read access for group.bar in all directories in the volume.

More flexible for a variety of situations. In particular, this allows administrators (or an arbitrary administrator-defined set of users) to override the volume policies, and set e.g. system:anyuser write on a particular directory if they so wish. No performance overhead at access-check time. All of the additional access checks are done during SetACL. Minimal end-user confusion. ACLs accurately represent exactly what rights different users have. Trying to set an ACL that violates the policy will result in EACCES, so they know the SetACL operation didn't work. It may be confusing as to why it did not, but at least it is clear that the ACL was not changed.

Volumes need to be 'audited' (or all of the ACLs just need to be set) to make sure they comply with the ACL policy, which can be very slow. Higher end-administrator confusion. This by far the most confusing method for administrators to set ACL policies.