On Fri, Sep 23, 2022 at 3:38 AM Christian Brauner <brauner@xxxxxxxxxx> wrote: > > On Thu, Sep 22, 2022 at 10:52:43PM -0500, Steve French wrote: > > Looks like the SMB1 Protocol operations for get/set posix ACL were > > removed in the companion patch (in SMB3, POSIX ACLs have to be handled > > Sorry, what companion patch? Is a patch in this series or are you > referring to something else? I found it - the patch order was confusing (I saw patches 4 and 27, but patch 5 was missed). The functions I was asking about were deleted in patch 27 in your series but readded in patch 5 which I had missed. On the more general topic of POSIX ACLs: - Note that they are supported for SMB1 (to some servers, including Samba) - But ... almost all servers (including modern ones, not just ancient SMB1 servers) support "RichACLs" (remember that RichACLs were originally based on SMB/NTFS ACLs and include deny ACEs so cover use cases that primitive POSIX ACLs can't handle) but for cifs.ko we have to map the local UID to a global unique ID for each ACE (ie id to SID translation). I am interested in the topic for how it is recommended to map "POSIX ACLs" to "RichACLs." I am also interested in making sure that cifs.ko supports the recommended mechanism for exposing "richacls" - since there are various filesystems that support RichACLs (including NFS, cifs.ko, ntfs and presumably others) and there are even xfstests that test richacls. > > by mapping from rich acls). Was this intentional or did I miss > > something? I didn't see the functions for sending these over the wire > > for SMB1 (which does support POSIX ACLs, not just RichACLs (SMB/NTFS > > ACLs)) > > I'm sorry, I don't understand. This is basically a 1:1 port of what you > currently have in cifs_xattr_set() and cifs_xattr_get() under the > XATTR_ACL_DEFAULT and XATTR_ACL_ACCESS switches. So basically, the > patches in this series just add almost 1:1 copies of > CIFSSMBSetPosixACL() and CIFSSMBGetPosixACL() just that instead of > operating on void * they operate on a proper vfs struct posix acl. So > nothing would've changed behavior wise. Ofc, there's always the chance > that I missed sm especially bc I'm not a cifs developer. :) > > > > > pSMB->SubCommand = cpu_to_le16(TRANS2_SET_PATH_INFORMATION); > > pSMB->InformationLevel = cpu_to_le16(SMB_SET_POSIX_ACL); -- Thanks, Steve
