Bug 8757 - Recursive links over local SMB mounts cripple server
Recursive links over local SMB mounts cripple server
Status: NEW
Product: Samba 3.6
Classification: Unclassified
Component: File services
3.6.3
All Linux
: P5 normal
: ---
Assigned To: Volker Lendecke
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-02-10 23:43 UTC by Peter Scott
Modified: 2012-02-12 03:03 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Scott 2012-02-10 23:43:08 UTC
We have discovered that if the same machine is acting as client and server, and there is a symlink pointing to *itself* through the SMB mount, that stat() on the link brings the machine to its knees.  Multiple smbd processes fork, the stat() takes either a long time to return or never returns, the system runs out of file descriptors, that kind of stuff.  We have reproduced this with the latest version of Samba and are quite prepared to post the precise details to reproduce it and what we saw, but I think those will be unnecessary once you understand the issue.

Let me give an example.  Suppose the directory /local/foo is exported as share 'foo'.  Now suppose that the client - running on the same machine, remember - mounts that with

    mount -t cifs //localhost/foo /mnt/foo

And now I do:

    cd /local/foo
    ln -s /mnt/foo/bar bar

If I now do anything that stat()s bar, like ls -l /mnt/foo, we're off into NeverNeverLand.

I *know* that sounds like a stupid thing to do in the first place.  Bear with me.

It seems clear to me what's happening - the server gets the request to stat the file, which is linked to an SMB mount, so the stat follows the SMB mount again, and so on.  It's not a recursive symlink that's detectable to the server the same way that it would be if it were linked to /local/foo/bar.  But perhaps it could be detected in the client - am I stat()ing something that's a link to itself on a share that's mounted from localhost - so I want to ask whether the developers want to take it on anyway.

So why are we doing something so asinine?  (1) Why do we have a SMB client running on the same machine as its server?  We have excellent reasons irrelevant here relating to managing authorizations and ownerships for a shared web hosting environment accessed by multiple sharing protocols.  Our architecture would be more complicated if we didn't do that.

(2) Why are we linking a file to itself?  It was one of our users on the shared space that did it - *by accident*.  Three times, no less.  Some fluke move of files to the wrong place.  But it took down the system for everyone.  (Yes, finding the cause was as hard as you might imagine, and then some.)  The users told us, not unreasonably, that no one user should be able to deny everyone else service.  We agree.  Here we are.  Trying to tell management at this point that this was a fluke that can't reasonably be expected to recur, or to tell all our users to make sure that they don't do this by accident - not going to happen.

Absent some change to Samba, our best bet is likely to run iNotify to look for symlinks being created and axe any recursive ones.  But since we couldn't find any indication that anyone has run into this problem before, we wanted to give the Samba developers an opportunity to respond.  Is this something we might see addressed in either the near future or at all?  Thanks.
Comment 1 Derrell Lipman 2012-02-11 01:46:04 UTC
Changed component. Not really a problem of libsmbclient.
Comment 2 Jeremy Allison 2012-02-11 03:08:12 UTC
This is a *HORRIBLE* thing to do to smbd. It's essentially cruel and unusual punishment. I'm not sure of what to say other than "don't do that", but let me think about it some.

Jeremy.
Comment 3 Simo Sorce 2012-02-11 04:20:30 UTC
(In reply to comment #2)
> This is a *HORRIBLE* thing to do to smbd. It's essentially cruel and unusual
> punishment. I'm not sure of what to say other than "don't do that", but let me
> think about it some.

Jeremy I guess we could detect if a file is on a network (or just cifs mounted) mounted filesystem and simply deny any operation in that case. We do not support re-sharing network filsystems after all.
For the usual crowd of "but it works for me" we could have an option to re-enable it but that defaults to disable.
Comment 4 Volker Lendecke 2012-02-11 10:26:33 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > This is a *HORRIBLE* thing to do to smbd. It's essentially cruel and unusual
> > punishment. I'm not sure of what to say other than "don't do that", but let me
> > think about it some.
> 
> Jeremy I guess we could detect if a file is on a network (or just cifs mounted)
> mounted filesystem and simply deny any operation in that case. We do not
> support re-sharing network filsystems after all.
> For the usual crowd of "but it works for me" we could have an option to
> re-enable it but that defaults to disable.

Isn't that what the "dont descend" option is for? Shall we add to that a "veto file system" option?
Comment 5 Peter Scott 2012-02-12 03:03:13 UTC
Yes, it is brutal abuse of smbd.  If it were just our system, we would make sure we didn't do that.  But we have users...

An option to not traverse CIFS mounts in the server would work for us.  If it was generalized to all network mounts it would not, we are mapping NFS mounts into CIFS shares.  Not that I'm expecting a solution specially for us, you understand, just pointing out one environment here.