2015-09-23 21:18 GMT+02:00 J. Bruce Fields <bfields@xxxxxxxxxxxx>: > On Tue, Sep 22, 2015 at 03:11:08PM -0400, bfields wrote: >> user aces like owner aces what you intended to do, >> and if so, why? > > That does look wrong to me; in an example like: > > file owner bfields > mask 0700, not WRITE_THROUGH > bfields:rwx::allow > > The permission algorithm grants nothing to anyone, but it looks to me > like richacl_apply_masks just leaves this as > > bfields:rwx::allow > > but it would give the right result (an empty/deny-all ACL) if it weren't > for this odd case here. In POSIX ACLs, only the entry that best matches the process determines the access permissions. For the file owner, this would always be the "user::" entry, and such an entry always exists. In richacls, permissions from multiple entries do accumulate; the permission check algorithm does not pick a "best match". When bfields owns a file and a "bfields:rwx::allow" entry exists, denying rwx access to bfields would be very surprising. It makes more sense to put user entries that match the current owner into the owner class, and apply the owner mask instead of the group mask. This was working in an earlier version but apparently broke at some point. So the result that richacl_apply_masks computes here is correct, and the permission check algorithm needs a little fix. Thanks, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
