[Samba] Symlink bugs with SMB3 unix extensions

[Nikkos Svoboda]

On 12/18/2025 3:00 PM, Jeremy Allison via samba wrote:
> On 12/18/25 11:35 AM, Ralph Boehme via samba wrote:
>> On 12/18/25 8:32 PM, Jeremy Allison via samba wrote:
>>> On 12/18/25 10:25 AM, Nikkos Svoboda via samba wrote:
>>>> I can simply think that this *might* not be intended behavior for 
>>>> unix extension clients. Is this intended behavior for this setting 
>>>> combo?
>>>
>>> Yes. Setting "wide links = yes" and "allow insecure wide links = yes" 
>>> always hides all symlinks from clients. It's dangerously insecure
>>> and the settings remain for legacy smb.conf files and cases where
>>> the admin knows what they are doing. As I recall setting this
>>> does always generate a warning in the log.
>>
>> I wonder though if "follow symlinks = no" being forced by SMB3 POSIX 
>> should trump "wide links = yes" and "allow insecure wide links = yes" 
>> in theory? So this might be a bug.
>>
> 
> I think setting "wide links = yes" and "allow insecure wide links = yes"
> deliberately turns off SMB3 POSIX, but I haven't had time to check.
> 

    It does not appear to turn off POSIX. With both of the settings set 
to "yes". Clients can still mount with the "posix" mount option, 
interact with posix permissions, create a fifo file, and such.

    As far as I know, unlike SMB1 unix extensions, there's no means for 
an SMB3 POSIX client to create a symlink such that the server will 
create an actual symlink on its filesystem. The "symlink=unix" option 
does not appear to be supported with SMB3 unix extensions. All other 
symlink options create regular files, in some way (mfsymlinks, extended 
attribute on a file, etc.. ).
    If that's true, then in a sense, the danger with wide links only 
exists with SMB1 unix extensions, since an SMB3 client has no means to 
create an "actual" symlink on the server's file system (with one set of 
mount options) that the server will then follow "server side" (with a 
windows client or without the posix mount option). The only way for a 
"server side" symlink to be created is for an admin of the server to 
intentionally create a symlink on the server's filesystem.
    So, it would seem that the legacy behavior wouldn't be needed with 
SMB3 extensions, since that behavior can't be re-created with SMB3 POSIX 
anyway... clients can't create actual symlinks on the server filesystem.


    From a different perspective, perhaps being wrong about the above:

    If the purpose of the behavior is solely to keep a compatible, 
legacy behavior , then that's the answer. However, if there's an intent 
to provide, as a current supported feature, server settings to allow a 
server to choose to follow symlinks "server side," even for POSIX 
clients, then that ability would also potentially be desirable without 
having to enable insecure wide links.
    I don't myself have a use case for this, but I imagine if a site 
did, then there would be use cases where someone would want to have a 
server follow symlinks only within the share definition, which wouldn't 
require enabling wide links. As far as I can tell, that ability to 
follow symlinks, but without also enabling wide links, is not currently 
possible for POSIX clients.