I have Windows 2016 share that is mounted to Linux (kernel version 4.13), using CIFS version 3.0. However, I can not get ACL on the files in the share. The code is fairly basic: char buf[65536]; ret = getxattr(argv[1], "system.cifs_acl", buf, 65536); printf("getxattr: ret = %d, err = %s\n", ret, strerror(errno)); And I always get this error: root@cdm-node-hy4bn4-j6h2q52:~# ./xattr /tmp/windowsmount/source/regular.txt getxattr: ret = -1, err = Operation not supported Using vers=2.0 also fails. Using vers=1.0 succeeds.
Created attachment 275979 [details] tcp trace of the SMB session
What are the mount options?
Fairly basic: mount -t cifs -o vers=3.0,user=xxx,password=yyy //server/share /mymountdir
From the tcp trace, it looks the protocol exchange seems to be ok, Windows side returns ACL correctly in the response, but somehow kernel returns error to getxattr() caller.
No issues with 4.12 and SMB vers 3.0 $ ./acl /mnt/ssp/file1 getxattr: rc: 164, err: Success
We have noticed this happens to small acl, so can you try reduce the acl size to minimum?
Building 4.17, should be able to test and debug once it is done and installed. I have Windows 10 to test against, will check whether the problem manifests against SMB3 on that Windows 10 box.
I am down to basic minimum acl size of 120 (only R permission). Not sure how to go reduce acl size than that...
This is the security descriptor of size 120 REVISION:0x1 CONTROL:0x9404 OWNER:S-1-5-21-3154474055-481044923-3729397801-1002 GROUP:S-1-5-21-3154474055-481044923-3729397801-513 ACL:S-1-5-21-3154474055-481044923-3729397801-1002:ALLOWED/0x0/R If you use getcifsacl or smbcacls on this file, do they succeed? e.g. getcifsacl <file_name_on_mounted_share> or smbcacls //<server_name_or_ip>/<share_name> <file_name> -U <user_name> $ smbcacls //192.168.1.67/sspshare1 file1 -U shirish Enter shirish's password: REVISION:1 CONTROL:SR|PD|DI|DP OWNER:DESKTOP-6EQAVAF\shirish GROUP:DESKTOP-6EQAVAF\None ACL:DESKTOP-6EQAVAF\shirish:ALLOWED/0x0/R
No errors on 4.17 rc3 ~/acl /mnt/ssp/file1 getxattr: rc: 104, err: Success I compared wireshark trace and the only difference (12 bytes) is because of additional subauthorities in owner in the security descriptor which should not be cause of the problem. Not sure how to recreate the problem...
# mount -t cifs -o "vers=3.0,user=xxx,password=yyy" //10.0.28.166/share /tmp/mount # getcifsacl /tmp/mount/smb_test.txt WARNING: unable to initialize idmapping plugin: /etc/cifs-utils/idmap-plugin: cannot open shared object file: No such file or directory getxattr error: 95 REVISION:0x0 CONTROL:0x0 Can you try smaller ACL size? In my earlier trace, the ACL size is 92 bytes.
Not sure how to, down to basic ACE, will need to figure out a way to reduce subauthorities....
I changed owner to Local (S-1-5-19) which has no subauthorities and so ACL size is down to 88 and I see the error... ~/acl /mnt/ssp/file1 getxattr: rc: -1, err: Operation not supported Working on resolving this...
Created attachment 276271 [details] patch to fix check for minimum security descriptor size during response to get info
Created attachment 276305 [details] patch to fix check for minimum security descriptor size during response to get info
Posted the patch to cifs mailing list.
This has been checked in a while back as : commit ee25c6dd7b05113783ce1f4fab6b30fc00d29b8d Author: Shirish Pargaonkar <shirishpargaonkar@gmail.com> Date: Mon Jun 4 06:46:22 2018 -0500 cifs: For SMB2 security informaion query, check for minimum sized security descriptor instead of sizeof FileAllInformation class Validate_buf () function checks for an expected minimum sized response passed to query_info() function. For security information, the size of a security descriptor can be smaller (one subauthority, no ACEs) than the size of the structure that defines FileInfoClass of FileAllInformation. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199725 Cc: <stable@vger.kernel.org> Signed-off-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com> Reviewed-by: Noah Morrison <noah.morrison@rubrik.com> Signed-off-by: Steve French <stfrench@microsoft.com>