[PATCH RFC] s3: smbd: Consistently map EAs to user namespace
kobras at puzzle-itc.de
Fri Sep 30 14:20:15 UTC 2022
Am 29.09.22 um 14:17 schrieb Ralph Boehme:
> 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.
Fair enough. The current SMB implementation in the Linux kernel
unconditionally adds a 'user.' prefix to names returned from
SMB_INFO_QUERY_ALL_EAS/SMB2_FILE_FULL_EA_INFORMATION. IOW it already
assumes the proposed restriction to only the 'user' namespace, and
reports an incorrect name for EAs from other namespaces.
Exposing the raw (unmapped) name only makes sense if namespaces other
than 'user' should be accessible from the generic EA interface. Have
there been any plans to do so? For comparison, the recently added
support for NFSv4.2 xattrs is restricted to 'user' as well. As far as I
understood, that's because from the point of view of a network
filesystem, the 'user' namespace is special as by definition it is
interpreted by higher levels, and can just be passed around verbatim. In
contrast, the semantics of other EAs are defined at the system level.
They require interpretation when transferred between different systems,
and cannot just be passed through a generic interface. For example, even
if we restricted ourselves to Linux systems, we could not just expose
'system.posix_acl*' as generic EAs, but instead need a dedicated
interface that takes the differences between client and server (uid/gid
mapping in this case) into account.
So back to the proposed change, there's good reason to keep the
restriction even in the future. In any case, it shouldn't make the
situation any worse for in-kernel SMB on Linux because it just does what
the client-side code already assumes.
Puzzle ITC Deutschland
+49 7071 14316 0
Puzzle ITC Deutschland GmbH
Sitz der Gesellschaft: Eisenbahnstraße 1, 72072
Eingetragen am Amtsgericht Stuttgart HRB 765802
Lukas Kallies, Daniel Kobras, Mark Pröhl
More information about the samba-technical