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...).>> ?From that thread it seems Jeremy had some ideas, not sure how this >> went and whether there's some option I've missed that would do the trick. > > This is still being worked (SMB2 UNIX Extensions that is) -- any help is > welcome! :)Good to know, thanks! :) Giuseppe
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>