smbd: allow reading files based on FILE_EXECUTE access right

BUG: https://bugzilla.samba.org/show_bug.cgi?id=12149

Signed-off-by: Uri Simchoni <uri@samba.org>
Reviewed-by: David Disseldorp <ddiss@samba.org>
Autobuild-User(master): David Disseldorp <ddiss@samba.org>
Autobuild-Date(master): Thu Aug 18 18:58:22 CEST 2016 on sn-devel-144

diff --git a/selftest/knownfail b/selftest/knownfail
index 41cad445309f69b69b7c7e6d46005cbfd4424d92..ffcaf0682932e0bb833e0373baccc51baae616a2 100644 (file)
--- a/selftest/knownfail
+++ b/selftest/knownfail
@@ -286,10 +286,7 @@
 ^samba4.krb5.kdc.*as-req-aes.*fl2000dc
 # nt4_member and ad_member don't support ntlmv1
 ^samba3.blackbox.smbclient_auth.plain.*_member.*option=clientntlmv2auth=no.member.creds.*as.user
-#new read tests fail
+#nt-vfs server blocks read with execute access
 ^samba4.smb2.read.access
-^samba3.smb2.read.access
-#new copychunk tests fail
+#ntvfs server blocks copychunk with execute access on read handle
 ^samba4.smb2.ioctl.copy_chunk_bad_access
-^samba3.smb2.ioctl.copy_chunk_bad_access
-^samba3.smb2.ioctl fs_specific.copy_chunk_bad_access

diff --git a/source3/smbd/smb2_glue.c b/source3/smbd/smb2_glue.c
index b41775d882b85c4e6faf1817c1139895f3679081..0bb34be454f76c47218adbf330d26ec377dc5255 100644 (file)
--- a/source3/smbd/smb2_glue.c
+++ b/source3/smbd/smb2_glue.c
@@ -48,6 +48,22 @@ struct smb_request *smbd_smb2_fake_smb_request(struct smbd_smb2_request *req)
                         FLAGS2_32_BIT_ERROR_CODES |
                         FLAGS2_LONG_PATH_COMPONENTS |
                         FLAGS2_IS_LONG_NAME;
+
+       /* This is not documented in revision 49 of [MS-SMB2] but should be
+        * added in a later revision (and torture test smb2.read.access
+        * as well as smb2.ioctl_copy_chunk_bad_access against
+        * Server 2012R2 confirms this)
+        *
+        * If FILE_EXECUTE is granted to a handle then the SMB2 server
+        * acts as if FILE_READ_DATA has also been granted. We must still
+        * keep the original granted mask, because with ioctl requests,
+        * access checks are made on the file handle, "below" the SMB2
+        * server, and the object store below the SMB layer is not aware
+        * of this arrangement (see smb2.ioctl.copy_chunk_bad_access
+        * torture test).
+        */
+       smbreq->flags2 |= FLAGS2_READ_PERMIT_EXECUTE;
+
        if (IVAL(inhdr, SMB2_HDR_FLAGS) & SMB2_HDR_FLAG_DFS) {
                smbreq->flags2 |= FLAGS2_DFS_PATHNAMES;
        }