| Message ID | 20240929185053.10554-1-pali@kernel.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | cifs: Improve support for native SMB symlinks | expand |
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 > >
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.
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(-)