linux-kernel - Re: [PATCH 0/7] cifs: Improve support for native SMB symlinks

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: <CAH2r5muq4S+w-W-J+YMuJ9RzPJsbmf6zKuGPN0H8DohXe--1uA@mail.gmail.com>
Date: Sun, 29 Sep 2024 17:03:31 -0500
From: Steve French <smfrench@...il.com>
To: Pali Rohár <pali@...nel.org>
Cc: 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 0/7] cifs: Improve support for native SMB symlinks

Merged patches 2, 3, 4 and 6 from this series into cifs-2.6.git for-next

For patch 1, seems like rename could get in the way of backports, and
is only a minor improvement (could consider it in the future for
6.13-rc if part of other cleanup/improvements, but lower priority)

For patch 5 it could be ok - but wanted more opinions on that ...
since wouldn't want it to break POSIX - e.g. what would happen with
this patch if a Linux server changed the target of a symlink from a
file to directory (or the other way around) - is there any risk of
breaking POSIX symlink semantics in a pure Linux->Linux case with this
patch?

For patch 7, it is relatively larger fix (and less important for pure
Linux workloads) so wanted some additional opinions/feedback on this
from others

On Sun, Sep 29, 2024 at 1:51 PM Pali Rohár <pali@...nel.org> wrote:
>
> This patch series improves interoperability of native SMB symlinks
> (stored in IO_REPARSE_TAG_SYMLINK reparse point) between Linux SMB
> client and Windows SMB server storage (NTFS).
>
> Fixed test cases by this patch series are:
>
> Fixes parsing of symlinks relative to the top of the export which can be
> created on Windows by:
>
>   mklink symlink \relative\path\from\export
>
>
> Fixes parsing of symlinks in absolute form which can be created on
> Windows by:
>
>   mklink symlink C:\absolute\path
>
>
> Fixes creating of symlinks pointing to directory. So Linux commands:
>
>   mkdir dir
>   ln -s dir symlink1
>   ln -s another_dir/ symlink2
>
> creates a symlink which would be now understood also by Windows as
> symlinks to directories.
>
>
> Fixes creating of symlinks pointing to current or parent directory.
> So following commands create valid symlink understood by Windows:
>
>   ln -s . symlink_cur
>   ln -s .. symlink_parent
>
>
> Fixes creating of absolute symlinks. Absolute symlinks on Windows are
> quite complicated due to nature of DOS/Win32 path form used by Windows
> applications and NT path form in which are symlink paths stored. Also
> complication is that NT object paths have different hierarchy than POSIX
> paths generally. Required information about NT object hierarchy used in
> native absolute symlinks are in comments in the last patch from this
> series.
>
> To resolve mentioned problems I chosse way which is used by WSL, its
> -t drvfs has mount option -o symlinkroot= which specify Linux path there
> should point absolute windows drive letter symlinks. This could make
> -t cifs mounts in WSL2 more compatible with symlinks coming from local
> NTFS disks mounted by -t drvfs.
>
> I'm not sure how good are these changes, but I think that they improve
> compatibility of symlinks between Linux and Windows systems. Maybe there
> is some better solution how to handle some of those issues?
>
>
> Pali Rohár (7):
>   cifs: Rename smb2_get_reparse_inode to smb2_create_reparse_inode
>   cifs: Improve creating native symlinks pointing to directory
>   cifs: Fix creating native symlinks pointing to current or parent
>     directory
>   cifs: Fix parsing native symlinks relative to the export
>   cifs: Fix parsing native symlinks directory/file type
>   cifs: Validate content of native symlink
>   cifs: Fix creating and resolving absolute NT-style symlinks
>
>  fs/smb/client/cifs_unicode.c |  17 +-
>  fs/smb/client/cifsglob.h     |   1 +
>  fs/smb/client/cifsproto.h    |   1 +
>  fs/smb/client/fs_context.c   |  22 ++
>  fs/smb/client/fs_context.h   |   2 +
>  fs/smb/client/inode.c        |   1 +
>  fs/smb/client/reparse.c      | 513 ++++++++++++++++++++++++++++++++---
>  fs/smb/client/reparse.h      |   4 +-
>  fs/smb/client/smb1ops.c      |   3 +-
>  fs/smb/client/smb2file.c     |  67 ++++-
>  fs/smb/client/smb2inode.c    |  15 +-
>  fs/smb/client/smb2proto.h    |  13 +-
>  12 files changed, 602 insertions(+), 57 deletions(-)
>
> --
> 2.20.1
>
>


-- 
Thanks,

Steve