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. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
