Message-ID: <20250829130104.jtjp2jlmd6infvtc@pali>
Date: Fri, 29 Aug 2025 15:01:04 +0200
From: Pali Rohár <pali@...nel.org>
To: Steve French <smfrench@...il.com>
Cc: ronnie sahlberg <ronniesahlberg@...il.com>,
	Jeremy Allison <jra@...ba.org>, Steve French <sfrench@...ba.org>,
	Paulo Alcantara <pc@...guebit.com>, linux-cifs@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: Do not use UID and GID from EAs

On Monday 11 August 2025 12:52:58 Pali Rohár wrote:
> On Tuesday 17 September 2024 16:19:08 Steve French wrote:
> > On Tue, Sep 17, 2024 at 3:45 PM ronnie sahlberg
> > <ronniesahlberg@...il.com> wrote:
> > >
> > > On Wed, 18 Sept 2024 at 06:37, Pali Rohár <pali@...nel.org> wrote:
> > > >
> > > > On Tuesday 17 September 2024 13:31:22 Jeremy Allison wrote:
> > > > > On Tue, Sep 17, 2024 at 10:29:21PM +0200, Pali Rohár wrote:
> > > > > > On Tuesday 17 September 2024 13:23:40 Jeremy Allison wrote:
> > > > > > > On Tue, Sep 17, 2024 at 10:06:00PM +0200, Pali Rohár wrote:
> > > > > > > > And seems that SMB2_OP_QUERY_WSL_EA is useful not only for reparse
> > > > > > > > points, but also for any regular file or directory as it can contain
> > > > > > > > UNIX mode and UID/GID ownership.
> > > > > > >
> > > > > > > uid/gid should *never* be exposed over the wire for SMB.
> > > > > > >
> > > > > > > That way lies madness.
> > > > > >
> > > > > > Hello Jeremy, if I understood wsl_to_fattr() function correctly then it
> > > > > > is already doing it, it fills uid/gid for stat() from data which were
> > > > > > exposed over the wire for SMB. Could you check that function if it is
> > > > > > truth?
> > > > >
> > > > > I'm sure the Windows implementation is doing it - however, any Linux
> > > > > server implementations should not do this (IMHO).
> > > > >
> > > > > It will break all SID -> uid / gid mapping that servers must
> > > > > carefully set up.
> > > > >
> > > > > On the wire - SIDs must be the only source of identity.
> > > >
> > > > Ok. But then I do not understand why Linux client parses and uses uid
> > > > and gids which are sent over the wire. If you are saying that the SIDs
> > > > must be the only source of truth then Linux client should rather ignore
> > > > uid and gid values?
> > >
> > > What I think Jeremy is refering to is that mixing uids and sids in the
> > > protocol itself is
> > > a protocol design mistake.
> > > Because this means that some PDUs in the protocol operate on SIDs but
> > > others operate on
> > > UID/GIDs and this means there is great risk of mistakes and have the
> > > sid<->uid mapping return
> > > different results depending on the actual PDU.
> > >
> > > Sometimes the sid<->uid mapping happens in the server, at other times
> > > the mapping happens in the client
> > > and it is very difficult to guarantee that the mapping is consistent
> > > across PDUs in the protocol as well as across different clients.
> > 
> > Yes - agreed.
> > 
> > SIDs are globally unique and should always be used/sent over the wire
> > (never send or use the local uid/gid which is not guaranteed to be
> > unique).  Whether retrieving ownership information via
> > the SMB ACL or via an SMB3.1.1 POSIX response, the SID is the correct
> > thing to send/use in the protocol.  For cases where the client is not
> > domain joined, the UID/GID can be encoded in the SID, for cases that
> > are domain joined the Linux UIDs/GIDs can be mapped consistently via
> > the SID.
> > 
> > -- 
> > Thanks,
> > 
> > Steve
> 
> Hello Steve, based on the above discussion I'm proposing a change which
> stops parsing UID and GID values stored in EAs on the SMB server for
> SMB2 and SMB3 dialects. Change is in the attachment.
> 
> Steve, Ronnie, Jeremy and Paulo, could you review this change?

Hello, have you looked at the proposed change in the previous email?

Powered by blists - more mailing lists