[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAN05THTVav8HOCk6V+5eg-BTESZDBx2BuQOF1c=Vn2dFv_UNxw@mail.gmail.com>
Date: Wed, 18 Sep 2024 06:44:39 +1000
From: ronnie sahlberg <ronniesahlberg@...il.com>
To: Pali Rohár <pali@...nel.org>
Cc: 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 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.
>
Powered by blists - more mailing lists