linux-kernel - Re: [PATCH] cifs: Fix getting reparse points from server without WSL support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAH2r5muUioziUN7mRFUAOV3tGPMLnb949j70GKYnRM2LygAWVQ@mail.gmail.com>
Date: Tue, 17 Sep 2024 16:19:08 -0500
From: Steve French <smfrench@...il.com>
To: ronnie sahlberg <ronniesahlberg@...il.com>
Cc: Pali Rohár <pali@...nel.org>, 
	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: [PATCH] cifs: Fix getting reparse points from server without WSL support

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