Alternate approaches to lock/dead-client problem.

[Nicolas Williams]

On Tue, Jan 26, 1999 at 10:39:49AM -0500, David Collier-Brown wrote:
> 	I'd like to suggest looking at the locking/oplocking behavior
> 	instead of directly killing the smbd:  if a lock is held on a
> 	file X by a client Y, and another lock is requested, then
> 	we may want to check that the lock's holder (Y') is still alive.

> 	If this were just an oplock, the probable behavior would be
> 	for the server to send a "break" request to the client, the
> 	client be fond to be dead and the server to clean up...

Yeah, but then there's deny modes.

> 	Arguably, any other lock request from the same client should
> 	trigger a similar check for the death of the "first" client.

This would be a good thing to do. My workaround is a very crude
implementation of what you suggest. I'd love to see a source level fix
however.

> 	As a non-expert, this raises two questions in my mind
> 		1) is there room to store client IDs in the locks structure?
> 		  I see a flock64 used as SMB_STRUCT_FLOCK, which had a
> 		  pid, which will tell us the nmbd to ask, but I don't see
> 		  an obvious and inexpensive way to ask "which client"

Dunno. Haven't checked (I'm not a Samba developer :) but I suppose that
Samba can be modified to keep track of connected clients in a similar
way to how it keeps track of locks held by clients.

Thus, if a new smbd process has a client connected for which there is
another smbd then the new smbd could send a signal to the old smbd which
would prompt the old smbd to check that the client is still alive and,
if not, then die.

But the question is: is it correct to assume that an SMB session over
TCP is abandoned when a new connection with the same parameters is
opened to the server?

That's my assumption. And if safe then there's no need to implement a
check for abandoned connections; if they're logically abandoned, then
drop them. The worst thing that could happen is that you're dropping a
valid connection, prompting the client to reconnect. But then, if the
old connection is just dropped with no checks that might open up a
connection-hijacking hack.

*shrug*

A word from Samba team members about this issue could help ;|

> 		2) could one reorder the locking logic so that the oplock
> 		   test comes first, which would presumably detect a dead
> 	           client at low cost... 

This, I believe, depends on the NT client. Unfortunately. I hope I'm wrong.

> --dave (trying to think of a third question) c-b
> -- 
> David Collier-Brown,  | Always do right. This will gratify some people
> 185 Ellerslie Ave.,   | and astonish the rest.        -- Mark Twain
> Willowdale, Ontario   | http://java.science.yorku.ca/~davecb
> Work: (905) 477-0437 Home: (416) 223-8968 Email: davecb at canada.sun.com


Nico