Re: [PATCH v2] smb: client: preserve leading slash for POSIX absolute symlink targets

[Paulo Alcantara <pc@manguebit.org>]

Steve French <smfrench@gmail.com> writes:

> When creating a native SMB symbolic link (CIFS_SYMLINK_TYPE_NATIVE) whose
> target is an absolute path on a mount that uses POSIX paths, the leading
> path separator was silently dropped from the stored symlink target.
>
> create_native_symlink() converted the target to UTF-16 with
> cifs_convert_path_to_utf16().  That helper is intended for share-relative
> SMB paths and therefore unconditionally strips a leading path separator.
> For an absolute POSIX symlink target the leading '/' is significant, so a
> target of "/foo/bar" was stored - and read back - as "foo/bar", even
> though the reparse point was still flagged as absolute
> (SYMLINK_FLAG_RELATIVE cleared).
>
> On a POSIX paths mount the symlink target is stored verbatim, so convert
> it directly with cifs_strndup_to_utf16() instead.  This preserves the
> leading separator, avoids the leading-backslash stripping that
> cifs_convert_path_to_utf16() also performs (a backslash is a valid POSIX
> filename character), and uses NO_MAP_UNI_RSVD to match the readback path
> in smb2_parse_native_symlink(), which always converts the target with
> cifs_strndup_from_utf16() / NO_MAP_UNI_RSVD.  This mirrors how the NFS and
> WSL reparse symlink creators convert their targets.
>
> The NT-style absolute symlink handling, which needs the "\??\" prefix and
> drive-letter colon preserved, continues to use cifs_convert_path_to_utf16()
> together with the existing masking of those bytes.
>
> Fixes: 12b466eb52d9 ("cifs: Fix creating and resolving absolute NT-style symlinks")
> Signed-off-by: Steve French <stfrench@microsoft.com>
> ---
>  fs/smb/client/reparse.c | 17 ++++++++++++++++-
>  1 file changed, 16 insertions(+), 1 deletion(-)

Reviewed-by: Paulo Alcantara (Red Hat) <pc@manguebit.org>