Am 1/18/21 um 2:12 PM schrieb Giuseppe Lo Presti:> On 18/01/2021 11:58, Ralph Boehme wrote: >> Am 1/18/21 um 11:41 AM schrieb Giuseppe Lo Presti via samba: >>> Following an old thread at [1] I wonder whether there's been any >>> thought/plan to implement symbolic links loop detection in smbd. >> >> what do you mean? smbd will detect loops because the kernel tells us >> about loops with ELOOP. > > Well, that's what I hoped, but facts match what Jeremy mentioned at the > time: > > > the clients will see them [symlinks] as nested directories and request > > the server to follow them until the OS runs out of recursion > > depth and returns errors. > > 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: $ ls -l /srv/samba/test/dir total 0 lrwxrwxrwx. 1 slow slow 1 Jan 18 14:15 link -> . ls /srv/samba/test/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 Works. Add another path component "link/" and we hit the kernel limit: $ ls /srv/samba/test/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/ ls: cannot access '/srv/samba/test/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/': Too many levels of symbolic links Now smbclient: 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/* . D 0 Mon Jan 18 14:29:10 2021 .. D 0 Mon Jan 18 14:29:10 2021 102687672 blocks of size 1024. 57521480 blocks available 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. -slow -- Ralph Boehme, Samba Team https://samba.org/ Samba Developer, SerNet GmbH https://sernet.de/en/samba/ GPG-Fingerprint FAE2C6088A24252051C559E4AA1E9B7126399E46 -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: <http://lists.samba.org/pipermail/samba/attachments/20210118/a7860b74/OpenPGP_signature.sig>
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