se-samba

[Luke Kenneth Casson Leighton]

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
 genuinely nasty.

 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
 seteuid().

 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
 server.

 what else.

 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.

 *thinks*...

 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-
 proxyer.

 there's a lot less code in it.

 l.