I'm generally in favor of considering this a bug and fixing it.
Thanks!
On Mon, Mar 20, 2023 at 04:21:12PM -0400, Jeffrey E Altman wrote:
> On 7 March Andrew Deason submitted a patch to OpenAFS documenting the
> existing behavior of the OpenAFS fileserver when computing Anonymous and
> Caller Access Rights if the IPv4 address from which the RXAFS RPC was
> received matches a PTS host entry and that PTS entry matches an Access
> Control Entry (ACE).
>
> https://gerrit.openafs.org/#/c/15340/
>
> Quoting Andrew's submission to the fs_setacl man page:
>
>"Combining _Negative rights_ granted from machine entries (IP
>addresses) and _Normal rights_ granted from non-machine entries (or
>vice versa) will generally not work as expected. Permissions granted
>by machine entries and by non-machine entries are calculated
>separately, and both sets of permissions are given to an accessing
>user. For example, if permissions are granted to an authenticated
>user or group (or _system:anyuser_), you cannot remove those
>permissions from specific hosts by adding machine entries to a group
>in an ACL in the _Negative rights_> section."
>
> The IBM AFS Administrator's Guide "Protecting Data in AFS" section states:
>
>"When determining what type of access to grant to a user, theFile
>Server first compiles a set of permissions by examiningall of the
>entries in the Normal rights section of the ACL. Itthen subtracts
>any permissions associated with the user (orwith groups to which the
>user belongs) on the Negative rightssection of the ACL. Therefore,
>negative permissions alwayscancel out normal permissions."
>
> IBM/Transarc AFS 3.2 introduced the granting of permissions based upon the
> host's IPv4 address in addition to those granted to the caller. The
> implementation evaluates the caller's rights independently of the host's
> rights and then ORs the results. This approach violates the statement that
> negative permissions always cancel out normal (aka positive) permissions. If
> a caller is granted "read" but there is a matching negative "read" ACE (aka
> permission) for the host, the negative "read" ACE is ignored. Likewise if
> "lookup" is granted to the host but the caller matches a negative "lookup"
> ACE, then the caller's negative "lookup" ACE is ignored.
>
> The problem can be demonstrated with a couple of examples. First, lets
> define some PTS entities and membership relations:
>
> * user: jane = 1000
> o member: system:authusers
> o member: system:anyuser
> o member: no-admin
> * user: 128.66.0.130 = 2000
> o member: local-hosts
> * group: no-admin = -100
> o member: jane
> * group: local-hosts = -500
> o member: 128.66.0.130
>
> Example 1: RXAFS RPC received from a host that is not a member of
> local-hosts
>
> ACL
>
> * system:anyuser: l; -none
> * system:authuser: lrk; -none
> * jane: none; -r
> * local-hosts: r; -none
>
> Rights:
>
> * system:anyuser: lookup
> * system:authuser: lookup, read, lock
> * jane: lookup, lock
>
> When "jane" accesses a file with this ACL the granted rights will be "lk"
> because the negative read permission cancels the positive read permission
> granted by the membership in the system:authuser group.
>
>
> Example 2: RXAFS RPC received from a host that is a member of local-hosts
>
> ACL
>
> * system:anyuser: l; -none
> * system:authuser: lrk; -none
> * jane: none; -r
> * local-hosts: r; -none
>
> Rights:
>
> * system:anyuser: lookup, read
> * system:authuser: lookup, read, lock
> * jane: lookup, read, lock
>
> In this case, even though "jane" is denied the "read" permission granted to
> members of "system:authuser" because of the negative "read" in the "jane"
> ACE she is granted the permission because of the positive read permission
> granted to "local-hosts" members. The granting of "read" permission to
> "jane" is an unexpected result!
>
>
> Example 3: RXAFS RPC received from a host that is not a member of
> local-hosts
>
> ACL
>
> * system:anyuser: l; -none
> * system:authuser: lrk; -none
> * jane: lrkwid; -none
> * local-hosts: none; -wida
>
> Rights:
>
> * system:anyuser: lookup
> * system:authuser: lookup, read, lock
> * jane: lookup, read, lock, write, insert, delete
>
> In this case, "jane" is granted all of the permissions other than "admin".
>
>
> Example 4: RXAFS RPC received from a host that is a member of local-hosts
>
> ACL
>
> * system:anyuser: l; -none
> * system:authuser: lrk; -none
> * jane: lrkwid; -none
> * local-hosts: none; -wida
>
> Rights:
>
> * system:anyuser: lookup
> * system:authuser: lookup, read, lock
> * jane: lookup, read, lock, write, insert, delete
>
> In this case, "jane" is granted all of the permissions other than "admin".
> However, because the RPC was issued from a host that is a member of
> "local-hosts" the expected result would be "jane" receiving only the
> "lookup, read, lock"
