On Wed, May 27, 2015 at 01:25:18PM +0200, Andreas Grünbacher wrote: > 2015-05-22 23:08 GMT+02:00 J. Bruce Fields <bfields@xxxxxxxxxxxx>: > > On Fri, Apr 24, 2015 at 01:04:11PM +0200, Andreas Gruenbacher wrote: > >> A richacl grants a requested access if the NFSv4 acl in the richacl > >> grants the requested permissions (according to the NFSv4 permission > >> check algorithm) and the file mask that applies to the process > >> includes the requested permissions. > > > > Is that right? Based on that I'd have thought that an acl like > > > > owner :r::mask > > group :-::mask > > other :-::mask > > bfields:r::allow > > > > would permit read to bfields in the case bfields is the file owner, > > because both the mask entries and the NFSv4 ACL would permit access. > > > > But I think it doesn't (because the "bfields" entry is subject to the > > group mask). > > The problem at cause here that if we treat the acl and masks completely > separately, we can end up with acl/mask combinations that don't have a > representation as "normal" acls. For example, this: > > owner:r::mask > group:-::mask > other:-::mask > group@:r::allow > > would grant the owner read access when in the owning group, but > wouldn't grant the owning group access. This is handled by applying > the group mask to all group-class entries; see this comment in the > code: OK, good, that makes sense, so I think all that's needed is some updates to documentation; for example: > /* > * Apply the group file mask to entries other than OWNER@ and > * EVERYONE@. This is not required for correct access checking This is a strange way to put it; it makes it sound like the logic here might not affect the access check result at all. And this routine is basically the definition of the access check algorithm, so the logic here is required. > * but ensures that we grant the same permissions as the acl > * computed by richacl_apply_masks() would grant. I mean, I do understand what you're saying here, but it's a slightly backwards way to put it.... > */ > > There is no necessity to also apply this rule to user entries matching the > current owner though; we can change that here and in richacl_apply_masks(). > > > But if I'm right, I'm not sure how to describe the algorithm concisely. > > Right, it's all a bit messy. We need to put some thought into how this will be explained in man pages and such, if you don't have that already. It's inherently a complicated ACL model, and hopefully this sort of corner case can be ignored most of the time, but we need a good complete explanation somewhere that a stressed sysadmin can follow if they need it.... I wish we could do something a little dumber and simpler, e.g., like http://docs.openafs.org/UserGuide/HDRWQ59.html but maybe it's not practical. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
