Bug 15024 - regression in 9a5a1fe148: Permission denied reading symlinks on SMBv1 shares
Summary: regression in 9a5a1fe148: Permission denied reading symlinks on SMBv1 shares
Status: NEW
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services (show other bugs)
Version: 4.14.0
Hardware: All All
: P5 regression (vote)
Target Milestone: ---
Assignee: Samba QA Contact
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-03-20 21:14 UTC by Alex Richardson
Modified: 2024-04-20 16:57 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Richardson 2022-03-20 21:14:58 UTC
I am using SMBv1 to expose a host directory to my QEMU FreeBSD VM using Qemu's builtin smbd support, using the following config file: https://github.com/CTSRD-CHERI/qemu/blob/ef6b6871875931eb77aaa36124fa5cee796d4782/net/slirp.c#L846. This works as expected with 4.12, but after updating to 4.14, I noticed that various programs failed to run correctly when using shared libraries from a SMB share. The actual file can be read correctly, but the versioned symlinks (to the actual file libfoo.so.1.1.1) result in permission denied errors.

I get errors such as the following:
`ld-elf.so.1: Shared object "libexpat.so.1" not found, required by "test-1"`

```
$ for i in libexpat.so*; do echo trying $i; stat $i; cat $i > /dev/null; echo $?; done

trying libexpat.so
18446744071662796549 3753720352 -rwxr-xr-x 1 root wheel 18446744073709551615 337448 "Jul 12 17:19:09 2021" "Jul 12 17:19:09 2021" "Jul 12 17:19:09 2021" "Dec 31 23:59:59 1969" 16644 659 0 libexpat.so
cat: libexpat.so: Permission denied
1
trying libexpat.so.1
18446744071662796549 3241636679 -rwxr-xr-x 1 root wheel 18446744073709551615 337448 "Jul 12 17:19:09 2021" "Jul 12 17:19:09 2021" "Jul 12 17:19:09 2021" "Dec 31 23:59:59 1969" 16644 659 0 libexpat.so.1
cat: libexpat.so.1: Permission denied
1
trying libexpat.so.1.8.1
18446744071662796549 90923038 -rwxr-xr-x 1 root wheel 18446744073709551615 337448 "Jul 12 17:19:09 2021" "Jul 12 17:19:09 2021" "Jul 12 17:19:09 2021" "Dec 31 23:59:59 1969" 16644 659 0 libexpat.so.1.8.1
0
```

I have bisected this change in behaviour:
9a5a1fe148cd82cd00d2ee913ec1ae90b9fb24e0 is the first bad commit
commit 9a5a1fe148cd82cd00d2ee913ec1ae90b9fb24e0
Author: Ralph Boehme <slow@samba.org>
Date:   Sat Jun 13 19:16:39 2020 +0200

    smbd: use open_pathref_fsp() in filename_convert_internal()

    Signed-off-by: Ralph Boehme <slow@samba.org>
    Reviewed-by: Jeremy Allison <jra@samba.org>

 source3/smbd/filename.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 45 insertions(+)


I know SMBv1 is going away and I would like to update to newer protocols but unfortunately FreeBSD's mount_smbfs only supports SMBv1.

Looking at the code in that commit it seems like OK is returned for
if (ucf_flags & UCF_POSIX_PATHNAMES) {
    status = NT_STATUS_OK;
}

Is this something I can change on the FreeBSD SMBv1 client side?
Comment 1 Björn Jacke 2024-04-20 16:57:45 UTC
Is this still a problem with latest 4.19 or 4.20 versions?