[PATCH RFC] s3: smbd: Consistently map EAs to user namespace
jra at samba.org
Mon Oct 3 18:32:34 UTC 2022
On Mon, Oct 03, 2022 at 11:29:17AM -0700, Jeremy Allison via samba-technical wrote:
>On Thu, Sep 29, 2022 at 02:17:57PM +0200, Ralph Boehme wrote:
>>On 9/27/22 13:10, Daniel Kobras via samba-technical wrote:
>>>The issues can be avoided with a consistent mapping between Windows EAs
>>>and the 'user' namespace in both directions, ie. no longer present EAs
>>>outside of 'user' as Windows EAs in SMB_INFO_QUERY_ALL_EAS and friends.
>>>Do you agree with this approach? Are there applications that rely on
>>>the current mapping of non-user EAs? Please let me know if I should
>>>submit the patch as a proper MR.
>>before jumping to action can we also please briefly consider the
>>Linux kernel mount case with SMB3 Unix Extensions and mount over
>>The proposed approach makes sense for Windows clients, maybe be
>>should incorporate exposing the raw namespace when UNIX extensions
>>are negotiated. In the end this is likely going to be a made via a
>>later MR in the future, but I'd like to see both cases considered
>>now that we're making changes.
>The SMB3 Unix Extensions can be fixed later via a new MR.
>The behavior for SMB3 Unix Extensions should be that GetEA/SetEA
>calls on a SMB3 Unix Extensions file handle should not hide the
>namespace from the client. From my experiments as root on Linux,
>the ListEA call only ever returns names from the user. namespace
Ah, that's not the case :-). I now checked with strace getfattr,
not just looking at it's output, and the listxattr() call on
Linux does return non user. namespace names, it's just the
getfattr tool that doesn't print them.
Still, that doesn't change the underlying fix for now.
More information about the samba-technical