ACL problem with NFSv4 and DELETE_ACCESS

Jeremy Allison jra at samba.org
Wed Jun 18 23:37:26 GMT 2008


On Tue, Jun 17, 2008 at 04:41:48PM +0200, Volker Lendecke wrote:
> Hi!
> 
> Attached find two patches that attempt to fix a bug we have
> when "real" ACLs and not just posix mode bits are used. With
> "real" I right now mean NFSv4, but others like for example
> the AFS ACL module are also affected.
> 
> The problem is in can_delete_file_in_directory(). It right
> now looks at the posix mode only if the owner of a directory
> wants to delete a file within it. This is wrong in all the
> more enhanced ACL schemes. It might be obvious, but it took
> a while for me to understand how this should really work: We
> are allowed to delete a file when either we have a direct
> DELETE right on the object or if that is not there we have a
> DELETE_CHILD right on the containing directory. The first
> attached patch implements this.
> 
> The second patch is necessary because the default rwxr-xr-x
> right on a normal file would map to the owner's DELETE bit
> on a file that is about to be deleted. This is wrong, in the
> non-acl case the right to delete a file is not determined by
> the permissions on the file itself. The changed checks in
> can_delete_file_in_directory take care of it by separately
> looking at the directory permissions.
> 
> The downside of this patch is that we don't use the fast
> path anymore in the non-acl case. I will measure next now
> much we actually lose. And, I'm not sure if all mappings in
> posix_acls.c are correct enough to actually make sure that
> we get the checks right if we push it through
> posix_get_nt_acl.
> 
> I'm not checking these patches in right away, because I need
> to do more tests, but I'd like to hear some feedback
> nevertheless, in particular from people who have worked with
> Posix and NFSv4 ACLs in production.

As discussed, they look really good with the change from
UNIX_ACCESS_RWX to (UNIX_ACCESS_RWX & ~DELETE_ACCESS) and
the re-arrangement to check the directory acl first.

Cheers,

	Jeremy.


More information about the samba-technical mailing list