linux-kernel - Re: [PATCH 8/8] cifs: Rename posix to nfs in parse_reparse_posix() and reparse_posix

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: <CAH2r5mt2jjirZdNCA9ZoENwtAdhfCCs6GxhZjwGtuQpj2q7cbA@mail.gmail.com>
Date: Sun, 29 Sep 2024 10:43:10 -0500
From: Steve French <smfrench@...il.com>
To: Ralph Boehme <slow@...ba.org>
Cc: Pali Rohár <pali@...nel.org>, 
	Steve French <sfrench@...ba.org>, Paulo Alcantara <pc@...guebit.com>, 
	Ronnie Sahlberg <ronniesahlberg@...il.com>, linux-cifs@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 8/8] cifs: Rename posix to nfs in parse_reparse_posix()
 and reparse_posix_data

On Sun, Sep 29, 2024 at 7:52 AM Ralph Boehme <slow@...ba.org> wrote:
>
> On 9/29/24 11:26 AM, Pali Rohár wrote:
> > Hello Ralph, thank you for information. So in case Samba is not
> > going to use IO_REPARSE_TAG_NFS as primary way to serve special
> > files, then it still makes sense to do this structure rename with my
> > patch?
>
> that's up to Paulo and Steve. I can only talk protocol/spec and server. :)

I don't think renaming that struct helps since to various servers we
will have to use reparse points to save special files, and could be
confusing to keep mentioning "nfs" for use cases in the client code
where not really related much to NFS.

> > Anyway, Windows clients mostly do not use IO_REPARSE_TAG_NFS.
>
> They don't *create* it, but they can *read* and present it. But I guess
> that's what you meant.
>
> > From my knowledge on Windows this tag is used only by Windows NFS
> > server. So scenario when Windows sends IO_REPARSE_TAG_NFS over SMB
> > would be rare... It would be needed to export NFS share via Windows
> > NFS server from SMB mount connected to Samba server.
>
> That's out of scope as far as SMB3 POSIX Extensions and I are concerned. :)
>
> > Note that Windows NFS client stores data about special files in EAs.
> > So for example if you mount export from Linux NFS server by Windows
> > NFS client, then NFS symlink would be visible to Windows
> > applications as regular file with "NfsSymlinkTargetName" EA. More
> > info is in this email: https://marc.info/?l=samba-
> > technical&m=121423255119680
> >
> > And this is what are Windows applications using if they want to
> > access data of special files. So application access
> > "NfsSymlinkTargetName" EA and not IO_REPARSE_TAG_NFS reparse tag.
>
> For symlinks SMB3 POSIX Extensions will use what Windows uses natively:
> IO_REPARSE_TAG_SYMLINK.
>
> > To my knowledge neither Samba, nor Linux CIFS client supports
> > "NfsSymlinkTargetName" EA for creating or parsing symlink.
>
> for Samba: yup.

Yes.  We would only want to support reading the NfsSymlinkTargetName
for the rare
cases where it would come up, but the default for creating symlinks on
the client
would be to use "mfysmlinks" (safer, client only symlinks, like Apple) when the
mfsymlinks mount parm is specified, otherwise use the default Windows
symlink type
when creating a new (server side) symlink remotely.

-- 
Thanks,

Steve