[Samba] symlinks loop detection in Samba?

Giuseppe Lo Presti
Tue, 19 Jan 2021 15:05:47 -0000

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: