[Samba] symlinks loop detection in Samba?

[Giuseppe Lo Presti]

On 18/01/2021 14:33, Ralph Boehme wrote:
> Am 1/18/21 um 2:12 PM schrieb Giuseppe Lo Presti:
> [...]
>>
>> So no ELOOP is triggered, and requests just keep piling up from the 
>> client.
>>
>> To reproduce, just create a link to '.' in a shared folder with 
>> `follow symlinks = yes` and look at its properties from Windows (or 
>> copy it over, but be ready to clean up the mess afterwards...).
> 
> I see the following:
> 
[...]
> Add another "link/":
> 
> smb: \> ls 
> dir/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/* 
> 
> NT_STATUS_OBJECT_PATH_NOT_FOUND listing 
> \dir\link\link\link\link\link\link\link\link\link\link\link\link\link\link\link\link\link\link\link\link\link\link\link\link\link\link\link\link\link\link\link\link\link\link\link\link\link\link\link\link\link\* 
> 
> 
> So I see the same expected behaviour over SMB as locally with ELOOP 
> mapped to NT_STATUS_OBJECT_PATH_NOT_FOUND.

Thanks a lot Ralph,

To be honest I did not wait for the 40 resolutions to be exceeded, as 
currently [*] implemented by the kernel, and thought that some loop 
detection would get triggered earlier (similarly to how e.g. `find -L` 
is implemented). Indeed I confirm that a Windows client looking to the 
properties of a shared folder with only one symlink to '.' does see 
exactly 40 folders, so it's all consistent.

At the same time, I acknowledge we must keep a loop protection in our 
filesystem, because in the general case it does take too much time to 
reach 40 path resolutions when a real folder structure is involved, and 
a DoS is already happening.

Cheers,
Giuseppe


P.S.: out of curiosity, why did you say "I hate to say, symlinks are 
fully supported"? :-)

[*] In case others are interested:
https://man7.org/linux/man-pages/man7/path_resolution.7.html