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
On Tue, Jan 19, 2021 at 04:05:47PM +0100, Giuseppe Lo Presti via samba wrote:> >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"? :-)Symlinks are a blight on a perfectly well designed filesystem. Once the VFS work is finished, expect an epic rant (talk :-) I'm planning to give :-). Not often I'll say this, but Microsoft got it right in Windows on this point.