Luke Kenneth Casson Leighton
lkcl at lkcl.net
Mon May 31 13:49:56 GMT 2004
On Mon, May 31, 2004 at 10:49:11PM +1000, Russell Coker wrote:
> > 2) all file operations go through the SMB layer: you have to
> > provide a means to separate user-contexts on the same SMB TCP
> > connection, and the best - i.e. quickest way with a minimal
> > coding impact - way to do that is to run two smbd servers,
> > one proxying to the other and to write an SMB client VFS plugin
> > that multiplexes out the user-contexts received over the same
> > TCP connection.
> I spent some time discussing these issues with Tridge at Linux.conf.au 2004.
> It seems that there is an interface in Samba to allow plug-ins which can be
> used for such things,
yes - the VFS layer, and _all_ samba SMB file operations - absolutely
all of them - go through this layer, by default.
> they aren't quite suitable for spawning an external
> process but I think it can be shoe-horned into it.
it's exactly the right fulcrum point, and anywhere else is
you wouldn't spawn an external process, you'd run an smb client
library which communicated with an already running smbd server
(on another high port number bound to 127.0.0.1)
and _that_ smbd server would fork() and use setuid() instead of
and the setuid() would be successful because, by using the
VFS layer to multiplex out all new TConX's, you are _guaranteeing_
that in the second smbd server that it will only _ever_ have to
deal with one TConX per process.
also, the second smbd server will be quite capable of dealing with
locking etc. because of the design of smbd.
also, the semantics of any multiplexing in the "front" smbd will
be dealt with correctly.
including that long-standing bug which can be demonstrated by
running an NT-based threaded benchmark client against a samba
oh yes: in the front-line smbd server, you'll be able to switch
off authentication and also any setuid calls, effectively
turning the smbd process into an SMB parser and nothing else.
you _might_ need to do some tweaking of the code to make it
proxy to the back-end SMB server for its authentication: you
_might_ be able to get away with setting it up as
"security = server", specifying the server it is to use
to perform authentication against to be the back-end SMB
server, and if you like, removing any seteuid calls to save
some processing time.
the last bit (saving processing time) shouldn't strictly be
necessary because hey, it's the same server, effectively,
so it's the same /etc/passwd and /etc/samba/smbpasswd file
etc. etc. or equiv.
_but_, ideally, if the front-line samba server can be "turned
into" just an SMB parser and forwarder, that'd be less code
to audit, less cpu cycles wasted, etc.
you _might_ want to consider looking at the "cliffs" project
because, in a funny way, the cliffs project might be a
better candidate for running the front-end SMB parser-and-
there's a lot less code in it.
More information about the samba-technical