CVS update: tng/source/passdb

[Luke Kenneth Casson Leighton]

On Tue, Jan 08, 2002 at 11:01:31AM +1100, Andrew Bartlett wrote:
> Luke Kenneth Casson Leighton wrote:
> > 
> > On Mon, Jan 07, 2002 at 03:16:05PM -0800, Andrew Tridgell wrote:
> > > [lckl]
> > > >  loadable module support is _not_ the way to do it.
> > >
> > > For those who have only just joined us the loadable module proposal
> > > goes like this:
> > >
> > > - allow smbd to load arbitrary .so module for any pipe
> > 
> >  likely to be insufficient.
> > 
> >  see message i sent in response to jfm's message
> >  describing the lm proposal, three months ago.
> 
> Do you have an archive reference? - or a one liner of what the 'lm
> proposal' was?.
 
 ..... eek.  no, i believe it was on samba-team mailing list
 [to which i am not subscribed].

 basically i remember that you had discussed a .so pipe
 module loading system in some detail, and jfm and others
 started describing it to me.

 i was not party to those discussions, and described a number
 of faults in it that needed to be addressed before it would 
 be useful.

 from what andrew describes, it looks like those issues have been
 addressed, albeit via an out-sourcing mechanism.

 i still have not been informed as to whether NT security context
 and NT user profile info may be transferred over this module API,
 although i suspect 99.9% that it can [or can be forced to].


> > > - a single .so can handle multiple pipes
> > > - the .so can have its own parameters in smb.conf
> > 
> > > That's the basic infrastructure. Then to allow compatibility with
> > > existing TNG pipes I suggested we have a single simple "glue" module
> > > that is loaded into smbd and interfaces to the existing TNG pipes
> > > interface. So you might have something like:
> > >
> > > pipe handler = *:pipe_tng_glue.so
> > >
> > > (meaning "for pipes that match the name * use pipe_tng_glue.so")
> > >
> > > or we could use symlinks in a pipe directory or whatever.
> > >
> > > >  "controlled" from HEAD is not the way to do it.
> > >
> > > well, if head is running then the packets will be going via smbd
> > > code. No choice about that.
> > 
> >   that's not the issue.
> > 
> >   how can an ARBITRARY dce/rpc-based program - NOT a .so - one
> >   that is UTTERLY INDEPENDENT of samba, run and register
> >   itself?
> > 
> >   if your pipe glue deals with this issue, then i will be
> >   amazed and will have finally got through to you, after just
> >   over two years of very unnecessary and painful experiences.
> 
> So let me see if I have this right:
> 
> glue_pipe_smbd.so is loaded in Samba.
> 
> glub pipe helper is running, listening on its own named pipe, waiting
> for simple rpc server to start.
 
  note [*1] for below.

> simple rpc server starts, (built with glue pipe lib) and asks for an
> interface.
> 
> glue pipe daemon enters this in tdb and creates pipe/socket, smbd picks
> it up on next reload_services (gluepiped hits it with a -HUP to help
> this along) and opens its end up, simple rpc server got the socket fd
> back across the named pipe.  (Doesn't even need root privs -
> gluepiped.conf has a simple acl for non-root daemons).
> 
> glue_pipe_smbd.so sets up the bindings and sends down the inbound
> connections - with the required state info.
> 

 the algorithm needed in pipe_tng_glue.so is the other way round to
 [*1], above.

 name of pipe from "pipe handler" option, above, is a string, pipe_name.

 string is put into "%s/.msrpc/%s", lp_lock_dir(), pipe_name.

 [where .msrpc directory is root-only 0700].

 unix domain socket is opened (client-call) with above string,
 root-only-accessible permissions.

 down unix domain socket, NetBIOS session info [remote_name,
 global_myname]; TCP client info (get_client_name(), get_client_addr());
 SMB user-profile information (NET_USERINFO_3 including
 NTLMSSP user-session-key validly filled in and also the NTLMSSP
 user-8-byte-security key validly filled in in the 40-byte "padding"
 field - andrew, you'll know what these are for, by now) are all
 sent.

 _then_ you simply hand the filedescriptor for the unix domain
 socket over to smbd, and any DCE/RPC packets that come in
 over the SMB IPC$ Trans2, SMBWriteX etc, you send down this
 filedescriptor, and then do a select (with a 30 second timeout)
 and then a read if there's any data, and respond in the Trans2
 and to any subsequent SMBreadXes if the data read was larger
 than an SMBtrans2 negotiated buffer size.

 that's all that the implementation of pipe_tng_glue requires.

 it could be made differently, but there is no need to.


 server-side implementation, in freedce, and samba-tng is just
 as simple:

 when receiving the endpoint string "ncacn_np:[pipe_name]":

 name of pipe from endpoint, above, is parsed, as pipe_name.

 string is put into "%s/.msrpc/%s", lp_lock_dir(), pipe_name.

 [where .msrpc directory is root-only 0700].

 unix domain socket is created, with above string,
 root-only-accessible permissions [if possible, but if not
 it doesn't matter, due to .msrpc directory being 0700].

 server listens on filedescriptor of ux-dom-sock, just as
 if it was any other socket.

 when connection is received:

 NetBIOS session info, TCP client info and user-security context
 info is received, decoded and stored in appropriate structures,
 for access by different subsystems as needed on demand by
 server applications.

 after that, the filedescriptor is treated as if it was a
 TCP or UDP dce/rpc connection.

 the critical difference is that the NT user-context info was
 transferred over the interface, plus sufficient information
 to answer get_client_name(), get_client_addr(), get_remote_name()
 and get_global_myname() function calls, if required [which
 even in freedce, believe it or not, they are, and this is
 catered for in the Freedce Transport API!].



 it's very, very, very simple, and can be implemented very, very
 quickly and simply.  code exists and has existed in the samba
 distribution that will do this job for over three years, now.


> --snip--
> 
> > > as I've mentioned, the packets go via smbd if they are using the SMB
> > > transport, so you really can't avoid a smb.conf.
> > >
> > > I don't imagine any of this
> > > (which has been said so many times before)
> > 
> > not to me it hasn't.
> > 
> > remember: you have not communicated to me any forward-thinking
> > or strategic software designs that will allow samba to rapidly
> > catch up with man-decades of microsoft proprietary practices,
> > except for the "glue" pipe idea.
> 
> This is a valid criticism of the entire way Samba is developed.  There
> is very little formal 'this is where we want to be, this is the way we
> will do it'.  
> 
> Most ideas in Samba are driven (at least initially) by the interest of
> one person - and then others either like it and help or the original
> author maintains it.  Very little of it is documented before the fact,
> and hopelessly little after the fact (I'm guilty of this as much as
> anyone).  This does mean that we don't get much of the 'forward-thinking
> or strategic software designs' until they are implemented.
 
 yes.  it has been observed before that samba development is not
 actually open source driven: it's actually a number of people
 working in independent areas, independently, doing their own thing,
 with very little in the way of code review etc.

 i don't do docs, either, btw :)

 when i was working full-time on TNG, i described designs on the
 lists [not that everyone got them, but even their comments and
 misunderstandings helped].

 then, there was at least _one_ person reviewing everything i did.
 for a while, that was anders blomdell.  then there was elrond: he
 did a _fantastic_ job.  i didn't actually realise this for a while
 but he reviewed _every_ single line of code i committed, with
 cvs diff, for close on to 18 months.


> This is how it works, its a pity at times, but I simply don't see it
> changing much in *any* OSS project.

the apache software foundation charter is a far superior way to
run an open source project, and it saves an _awful_ lot of hassle
and pain.

decisions can only be vetoed on _technical_ grounds, not "i don't
like that person, or i simply don't like that design, and i'm
not going to justify my dislikes".

i would strongly recommend that samba be run along the lines of
the ASF charter, with the concession that code does not have to
be owned by the samba software foundation [which doesn't exist]
or by andrew tridgell or someone, whoever, because of the current
ownership issues regarding samba code / GPL.

lkcl