Re: Potential smb/dfs regression introduced in kernel 6.6

[Paulo Alcantara <pc@manguebit.com>]

Steinbeißer, Sebastian	<Sebastian.Steinbeisser@lrz.de> writes:

> one thing I should have tested but forgot and now did:
> With the patch applied it is also possible to mount one of the SMB 3.1
> signed & encrypted shares that were originally affected on the
> production system and not only the test one!

Thank you very much for testing it!  The fix was sent upstream already.

BTW, I've noticed that the previous network trace showed that the
FSCTL_GET_REPARSE_POINT in the compounded response returned
STATUS_SUCCESS rather than STATUS_INVALID_DEVICE_REQUEST.  So I compared
it with other network traces and it seems that NetApp server is
requiring the client to open the file with FILE_READ_EA bit set in
SMB2_CREATE::AccessMask.  Windows client also sets FILE_READ_EA it, so
the FSCTL_GET_REPARSE_POINT request would probably work against NetApp
server.

I don't see anything in the specs that would require FILE_READ_EA being
set for FSCTL_GET_REPARSE_POINT, but could you please do another testing
with below changes on top of existing patch just to confirm my findings?

Thanks.

diff --git a/fs/smb/client/smb2inode.c b/fs/smb/client/smb2inode.c
index 062b86a4936f..e241a966997e 100644
--- a/fs/smb/client/smb2inode.c
+++ b/fs/smb/client/smb2inode.c
@@ -1258,7 +1258,8 @@ int smb2_query_reparse_point(const unsigned int xid,
 	cifs_dbg(FYI, "%s: path: %s\n", __func__, full_path);
 
 	cifs_get_readable_path(tcon, full_path, &cfile);
-	oparms = CIFS_OPARMS(cifs_sb, tcon, full_path, FILE_READ_ATTRIBUTES,
+	oparms = CIFS_OPARMS(cifs_sb, tcon, full_path,
+			     FILE_READ_EA | FILE_READ_ATTRIBUTES | SYNCHRONIZE,
 			     FILE_OPEN, OPEN_REPARSE_POINT, ACL_NO_MODE);
 	rc = smb2_compound_op(xid, tcon, cifs_sb,
 			      full_path, &oparms, &in_iov,