Glue Pipe dependencies
Luke Kenneth Casson Leighton
lkcl at samba-tng.org
Fri Jan 11 04:16:01 GMT 2002
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
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.
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,
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
[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,
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
save yourselves some time and use the NT apis in the first
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
- RNetWkstaUserLogon & RNetUserGetInfo
this will at least get things looking similar / similar
> > - 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
> > 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
d) easier understandability "if you are a newbie and want
to look at password authentication, go look at netlogond/
regarding what you consider to be "complexity":
there is a clean split between the client-side
implementation of the APIs and the server-side
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
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:
that's not all.
so the number of possible combinations is
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.
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?
More information about the samba-technical