[Pkg-samba-maint] Bug#439882: Bug#439882: Bug#439882: samba: Panic or segfault in Samba, and (unable to) core dump

Steve Langasek vorlon at debian.org
Fri Aug 31 09:35:48 UTC 2007


On Fri, Aug 31, 2007 at 09:28:41AM +0200, Paolo wrote:
> On Tue, Aug 28, 2007 at 06:30:12PM -0700, Steve Langasek wrote:

> > > # ls -l /var/run/samba/locking.tdb
> > > -rw-r--r-- 1 root root 40200 2007-08-28 21:05 /var/run/samba/locking.tdb

> > > so it seems that's root stuff and shouldn't have failed to write/expand it.

> > Right, so the file is going to be opened as root, but the locks are going to
> > be written after the process has changed uids to handle a client request; so
> > I think the write will fail because of that.

> hm, dosn't sound right - how is it supposed to write as non-root into 
> root-owned 0644 file?

Because once smbd has the file open, it doesn't need to be root to access
the file descriptor; but it does need to be root to exceed the filesystem
space limit.

> the failure is in expand_file() where it tries to make extra room in
> locking.tdb; it semmes to me that is (should be) done as root.

The locking is done in response to a user request; for security reasons it's
preferable that as much of this process as possible is done as the user, not
as root.

> > > Anyway, samba shows poor/bad behaviour here (ie buggy), it went into a tight
> > > loop, restarting smbd and firing off ~1000 panic msgs in a few mins and 
> > > filling up logs.

> > No, samba is doing exactly what it's asked to by the client.  smbd doesn't
> > restart itself, if you're getting multiple copies spawned it's because it's
> > being restarted by repeated client requests.

> ok - maybe: if it detects an error such that it won't be able to serve the
> client, well, it should refrain to try over and over.

It *doesn't* try over and over.  The "over and over" comes from the client,
*not* the server.

Furthermore, these are non-recoverable errors; in the general case, there's
no appropriate response code for a fileserver that can't correctly handle a
file serving request.  Aborting the connection is about the best you can do.

> Or perhaps should signal the client properly to give up. Hm, perhaps it
> does so already, hence smbmount (3.0.20b-1woody1) is guilty?

Yes, smbmount is the sort of client that would retry in the case of a server
disconnect.

> > > [2007/08/28 09:53:48, 0] lib/fault.c:dump_core(168)
> > >   unable to change to /var/log/samba/cores/smbdrefusing to dump core
> > > [2007/08/28 09:53:48, 0] smbd/server.c:main(847)

> > > there's no such /var/log/samba/cores/smbdrefusing and no core dump; /var/log
> > > is on another partition with plenty of space.

> > Well, presumably you could create these directories by hand and capture a
> > core dump that way, but if you're running out of disk space that doesn't
> > sound like it would be too helpful in this case.

> > On my system, these directories exist and appear to have been autocreated by
> > the daemons on start.

> I do see such dirs here:

> # ls -l /var/log/samba/cores/            
> drwx------ 2 root root 1024 2006-07-18 00:44 nmbd
> drwx------ 2 root root 1024 2007-08-28 10:17 smbd

> I 1st got confused by the missing ' ' in the msg, looking for dir
> '/var/log/samba/cores/smbdrefusing' :} - well I guess smbd would dump core
> as root, so I don't see any obvious reason why it didn't.

Because the failure didn't happen when the daemon was running as root, so
the process didn't have access to write it?  Resuming root privileges when
something has gone so wrong that a core file needs to be written would be
another potential security issue.

So really, the only bug I see here is the confusing log message with the
missing space after the directory name.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon at debian.org                                   http://www.debian.org/




More information about the Pkg-samba-maint mailing list