[PATCH RFC] s3: smbd: Consistently map EAs to user namespace
jra at samba.org
Mon Oct 3 18:29:17 UTC 2022
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 SMB?
>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
but it probably won't hust to just return the full namespace+name
for a ListEA on a SMB3 Unix Extensions file handle.
The nice thing about this is that it means that we can
cope with case-sensitive EA's - but only on a SMB3 Unix Extensions
IMHO this fix is good for now for the only existing case of
Windows handles, and we can fix SMB3 Unix Extensions up later.
More information about the samba-technical