On Friday 24 September 2010 20:55:51 Aneesh Kumar K. V wrote: > To be POSIX compatible we need to ensure that additional file access > control mechanisms may only further restrict the access permissions defined > by the file permission bits. That's true but I don't think it fully answers Jeff's question. With POSIX ACLs, the owner file permission bits are always identical to the permissions that the owner is granted through the ACL. Therefore, when acl_permission_check() is invoked on behalf of the owner, the ACL does not need to be consulted at all. For non-owners, the ACL always needs to be checked. This optimization is also true for richacls for the base permissions (read, write, execute), but: * Some permissions are more fine-grained than the file mode permission bits: richacls distinguish between write and append, and between creating directories and non-directories. * Some permissions go beyond what the owner is implicitly allowed or what can be expressed with read, write, execute: in a richacl, a user can be granted the right to delete a specific file even without write access to the containing directory and to take ownership of a file (* In addition, a richacl can grant the right to chmod and set the acl of a file, and to explicitly set the file timestamps. These are permissions which the owner is implicitly allowed anyway, so they are not relevant to this change to acl_permission_check().) To handle those cases correctly too, we always look at the acl for richacls, even for the owner. (We could still skip the acl check in some, but fewer, cases.) Thanks, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
