Luke Kenneth Casson Leighton
lkcl at lkcl.net
Tue Jun 1 15:31:19 GMT 2004
On Tue, Jun 01, 2004 at 03:44:10PM +0200, Volker Lendecke wrote:
> On Tue, Jun 01, 2004 at 01:35:47PM +0000, Luke Kenneth Casson Leighton wrote:
> > if you happen to already know the answer, i would be most grateful
> > if you could furnish me with that information - a very simple
> > and very brief confirmation of a) or b) is all i would expect.
> It's a), everything is done via a single tcp connection. One reason is that we
> want to mirror the behaviour that the server we proxy towards gives us as
> closely as possible. Separate smb connections give a difference that might have
> influence on the server's behaviour.
ah, thank you v. much volker.
... thing is that the difference on the behaviour is actually
in two instances:
1) a multi-threaded Win32 program accessing files on an SMB server
results in multiple SMB tconX's being initiated over the same
samba's behaviour in this instance is to BLOCK individual
SMB requests over the same TCP connection.
it therefore does not behave in the manner expected: namely
it does not emulate, in any fashion, a multi-threaded server.
2) SE/Linux does not have the concept (quite deliberately) of seteuid
and so in order to achieve the desired behaviour, multiple processes
must take the place of a single process going in-and-out-of user
context to root and another user etc.
there are many single-process ways in which 1) may be achieved:
emulating the same results as multi-threading in a single process
are a well-known computer science problem and in fact samba(3)
_has_ some code to this already, for emulating blocking locks:
if an SMB lock request fails (and it is deliberately not made
a blocking request) then the entire SMB packet is placed in a
queue and reprocessed later.
the same principle could theoretically be applied to all SMB
packets, but it gets a bit iffy.
there are not many ways in which 2) may be achieved.
a very useful samba(4) config option would be to make the SMB VFS
client not do SMB client multiplexing, but instead to have multiple
SE/Linux users will, i believe, be most grateful for such a
feature being available.
i hope that the samba developers can consider this request for the
benefit of the SE/Linux community and that of samba's, also.
More information about the samba-technical