RWX on a file does not imply DELETE access

Without this the changed checks in can_delete_file_in_directory give DELETE
access where there is none. So we can end up granting the ntcreate&x preparing
the unlink where we should not, which leads to a NT_STATUS_ACCESS_DENIED at
close time later, which in turn does *not* give the access denied error message
in the Windows GUI.

can_delete_file_in_directory will grant access now by looking at the directory
permissions.
(This used to be commit 51b5364c2afb3a18df4bec2bc1624760ccc01676)

diff --git a/source3/smbd/posix_acls.c b/source3/smbd/posix_acls.c
index b83e3b692a1dce81bdda62458fe6d3b7be700800..e92a263ca00aaa16a113f961980b20bbdefa7ad6 100644 (file)
--- a/source3/smbd/posix_acls.c
+++ b/source3/smbd/posix_acls.c
@@ -904,7 +904,7 @@ static SEC_ACCESS map_canon_ace_perms(int snum,
                if (directory_ace) {
                        nt_mask = UNIX_DIRECTORY_ACCESS_RWX;
                } else {
-                       nt_mask = UNIX_ACCESS_RWX;
+                       nt_mask = (UNIX_ACCESS_RWX & ~DELETE_ACCESS);
                }
        } else if ((perms & ALL_ACE_PERMS) == (mode_t)0) {
                /*