Glue Pipe dependencies

[Luke Kenneth Casson Leighton]

On Thu, Jan 10, 2002 at 06:54:22PM +1100, Andrew Bartlett wrote:

> (Ok, lets see if I can get those addresses right this time...)
> 
> Andrew Bartlett wrote:
> > 
> > I've been thinking about what things need to be done before the proposed
> > 'glue pipes' become a reality.  (For the archives:  This is the proposed
> > mechisim to allow TNG style RPC deamons to work on a Samba HEAD smbd).
> > 
> > I think its a great idea, as it must be a *hell* of a job maintaining
> > TNG, and I want it to be as easy as possible for people to do
> > interesting things.
> > 
> > The dependencies I can see are as follows:
> > 
> > Boring stuff (ie not done yet, but also pretty simple):
> > 
> > - generic module loading in samba
> > 
> > - allow modules to take over pipes
> > 
> > - supply modules with critical data (part lm hash, session key etc)
> > 
> >   I'm looking at making this practical for other reasons, much in the
> > way TNG carts around an info3 on the vuid (it won't be an info3, but it
> > will have the required info).

andrew: if you don't make it an info3, then as i said in earlier
email, you will have to _fake_ up an info3.  see samba-tng's
"lanman.c" - specifically, take a look at api_RNetUserGetInfo()
as one of the [two?] examples.

look at all the information that's still faked up, that i _still_
haven't filled in from the NET_USER_INFO3 structure!

fake user comment, fake full name, fake admin privs flag, fake
password age, fake last logon, logoff and count, fake logon server,
fake access hours, fake codepage - all of which is available
in the NET_USERINFO_3 structure!

look below at api_RNetUserGetGroups.

_again_ this information is in the NET_USERINFO_3 structure - 
the GroupRID and OtherSID lists should be used instead of
replying fake "Users", "Domain Users", "Guests" and
"Domain Guests".

api_RNetWkstaUserLogon.  same story.

api_WAccessGetUserPerms: _probably_ the same story :)


so despite what you or other people may think, carting around
some stupid NET_USER_INFO3 structure is in fact necessary.

which means that the part-lm-hash and user-session-key, imo,
might as well stay in the NET_USERINFO_3 structure, where i
believe it belongs.


> > 
> > - per-pipe module registration.
> > 
> > - glue pipe module
> > 
> > At this point an outside developer should be able to register their
> > module/pipe and it should 'just work'.
> > 
> > However, the modules people are interested in are from Samba-TNG, things
> > like netlogond, samrd, etc...  Here the dependencies begin to bite...
> > 
> > We need a few things in HEAD before most of these modules become any use
> > whatsoever:
> > 
> >  - tng_netlogond auth module.
> > 
> >   This is an authentication module that does the same job as
> > 'ask_local_netlogond' does in TNG.  Without this, both HEAD and TNG
> > would have to use the same smbpasswd file - it would be a mess.
> > Possible alternative is to do normal domain_client_validate() over
> > TCP/IP but I prefer this.

ack.

if you go over TCP/IP, your entry point is via another smbd process.
that means that one smbd will make a client-side call, resulting
in another smbd being forked to act as a proxy to communicate
with netlogond or netlogond.so-as-loaded-by-the-second-smbd _what_ever,
and it's just horrible, and you might as well add a bypass
mechanism whereby the first smbd may contact the netlogond or
netlogond.so-as-loaded-by-the-*first*-smbd _what_ever, direct.

bear in mind that netlogond.so-or-netlogond-whatever _also_ needs
to make samr and lsarpc client-side calls!!!!

so you _really need_ an outsourcing mechanism.


> >  - plugable password change mechisnm.
> > 
> >   If you use Samba-TNG's netlogond, you must also use TNG's samrd (as
> > far as I can tell, please correct me otherwise).  

correct.  and also samrd.

> > This certainly means
> > that password changes can't occur direct to HEAD's passdb.  

well if someone wants to write their own samrd that does this,
THAT'S OKAY!

and that's the whole _point_ of outsourcing.

the prospect of writing an entirely new samrd, cut/paste style
from someone else's, and adding your own passdb back-end, is
not quite so stupidly daunting as having to write an entire
_suite_ of support services, or your own smbd to have to back-end
it.

[which is why i look upon such suggestions as "go fork your own
project" or "do what thou wilst" with such utter contempt].


> > TNG has a
> > mechanism to this, and a similar one (possibly based/modeled/dependent
> > on the auth subsystem) needs to be written in HEAD.
> > 
> >  - lanman.c stuff.  Many of the lanman.c functions depend on data that
> > might be locked on the other side of the split.
 
 not if lanman.c is done properly.

 lanman.c is basically throwing out "fake" data, for the most part,
 _anyway_.

 it _really_ needs to get converted over to making client-side
 DCE/RPC function calls, thereby acting _purely_ as a proxy
 into "real" NT-compatible functionality.

 the other alternative is to make a "simple" API that both
 lanman.c and NT-alternative-services use.

 my opinion of this approach is quite low:

 - it means maintaining two sets of code

 - it means writing the damn "simple" APIs.

 - even if you wrote those APIs, the chances are that
   they would end up looking _exactly_ like the DCE/RPC
   client-side "NT-compatible" APIs _anyway_, so what's
   the point.

 save yourselves some time and use the NT apis in the first
 place.


 but, _for now_, i recommend that you basically leave lanman.c
 alone - it's for Win95 back-compat support.

 where you _have_ to touch it, i recommend you do:

 - RNetShareEnum & RNetShareGetInfo

 - RNetServerEnum (requires rev-eng and impl. of \PIPE\browsess!)
   but you don't _really_ have to do this one, it's not
   high priority.

 - RNetWkstaUserLogon & RNetUserGetInfo

 this will at least get things looking similar / similar
 functionality.



> >  - and a pile of things I can't think of - TNG is a separate project
> > (rather than a minor patch) for a very good reason
 
 ack!

> > I suppose the point is that while it will be fairly sane for new pipes,
> > pipes (and functionality) already implemented in HEAD could prove
> > difficult to replace.  

well, i believe that that is not the case.

domain_client_validate can be turned into what TNG does
now by adding support for connecting on loop-back
[to the netlogond.so or to the netlogond if there
is a tng_pipe_glue.so operating] by supporting
"\\." as the name of the PDC.

i also added a third INFO level in netlogond called
"general" to support plaintext passwords: this calls
all of the PAM stuff and legacy /etc/passwd crypt stuff
etc bleedin' etc.

and then you can cut out all of the direct-access
code in smbd and you get:

a) simpler, cleaner code

b) the same functionality as you have now!

c) less of a maintenance headache because one of
the entry-points into the password authentication
is removed.

d) easier understandability "if you are a newbie and want
to look at password authentication, go look at netlogond/
netlogond.so".


regarding what you consider to be "complexity":
there is a clean split between the client-side
implementation of the APIs and the server-side
implementation.

due to the nature of DCE/RPC, anyone conforming
to NDR and DCE/RPC may interoperate - that's the
whole damn point!!!!

so, here's what you can do.  client means "DCE/RPC
client implementation", server means "DCE/RPC server
implementation".


samba client -> samba server
tng client -> samba server
samba client -> tng server
tng client -> tng server

now, you may replace _any one_ of these, and still
expect to get the same results: that's the whole
point of the TNG architecture - subdividing along
clean lines for maintainability.

now, we haven't specified _which_ client or _which_
server may be replaced, and the list is:

samrd
netlogond
lsarpcd
svcctld
srvsvcd
wkssvcd
spoolssd
browsessd
winregd
eventmgrd

that's not all.

so the number of possible combinations is

2^^(N+1)

where N is the number of services.

there's therefore plenty of scope for anyone to replace
any one of the services _at their own choice_, and to
be able to prove to themselves in a couple of minutes
that "hey, things still work, let's try and improve
that crappy samrd in there.  oops, i pooed it up,
i'd better go back to using the _original_ samrd / samrd.so
from a stable release.  _for now_."

... but none of this can happen until the pipe_tng_glue.so
is in place.

lkcl

p.s. could someone _please_ refer me to andrew's document
or make a review of it as compared to the "Named Pipe"
RFC i sent, and haven't received any comments on?