mbox series

[0/7] cifs: Improve support for native SMB symlinks

Message ID 20240929185053.10554-1-pali@kernel.org
Headers show
Series cifs: Improve support for native SMB symlinks | expand

Message

Pali Rohár Sept. 29, 2024, 6:50 p.m. UTC
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(-)

Comments

Steve French Sept. 29, 2024, 10:03 p.m. UTC | #1
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@kernel.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
>
>
Pali Rohár Oct. 5, 2024, 2:07 p.m. UTC | #2
On Sunday 29 September 2024 17:03:31 Steve French wrote:
> 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?

I reworked the "cifs: Fix parsing native symlinks directory/file type"
patch to not change anything when server announce POSIX extension.
So V2 version of that patch would be active only for non-POSIX SMB
servers, like Windows SMB.

I hope that this would address all possible problems (not sure if there
are any) with Linux client <-> POSIX SMB server scenarios.