CVS update: tng/source/passdb

[Luke Kenneth Casson Leighton]

> I've never seen the patch myself - and I would be most interested to see
> the core changes required (and just looking at what TNG does isn't
> sufficient here, there is too much different).  
 
 not true.

 what you _think_ is sufficient [the transfer of all smb.conf
 options, i presume?  please tell me if this is correct or
 incorrect, or what else is "sufficient"] i went over the
 list of parameters, and found them to be mostly either
 misleading or irrelevant.

 the list of _relevant_ options are those related to
 the NetBIOS connection and to the tcp connection over
 which the NetBIOS connection is implemented.

 so that's:

 tcp params:

 - get_client_name()
 - get_client_ip()

 netbios params:

 - global_myname
 - remote_name

 smb-related params:

 - negotiated SMB protocol [little-used, i expect]
 - remote arch [an awkwardly, little-used derived param]
 
 then there's:

 - NT SMB user profile / login (a NET_USERINFO_3)
 - NTLMSSP 16 byte user-session-key [generated by the PDC]
 - NTLMSSP user-security info [8 bytes]


anything else?  it's basically all of the % params,
and [if you examine TNG's modified loadparm.c etc]
you'll see that they are subdivided into three
categories:

- tcp, netbios & smb connection-related [up to &inc smbnegprot]
- smb-user session-related  [smbsesssetupX]
- smb-user share-related [smbtconX]


the tcp, netbios & smb parameters are "stable" parameters
that do not change if the tcp / netbios / smb session
is "reused".  these are _valid_ parameters to transfer.

the smb-user session ones result in an NT SMB user-profile.
this is essential and valid information to transfer.


all other smb.conf-related parameters i believe are misleading,
or if _absolutely_ needed, which in almost all dce/rpc services
they are not, they can be back-derived from the NT user profile
information [NT username -> unix username -> getpwnam() ->
unix uid & gid -> getgroups(): voila.  for most of the dce/rpc
services this is utterly unnecessary and a waste of time:
we're in _NT_ space, here, not unix!].

for example, %L is the home directory, which
is derived from the unix password database.

on an anonymous connection, this is irrelevant.

however, user-password changing occurs over an
anonymous connection, and so does browsing.

additionally, spoolss clients split up into two
threads, one to do the printing and the other
to do "SpoolssChangeNotify".

the first thread is done over the user-authenticated
SMB session.

the *second* thread is done over a SECOND anonymous
SMB session, on a separate connection that forks off
a new smbd process!

this is an insane scenario that would be immediately
fixed and dealt with _correctly_ if the SMB info was
"handed off" to a decent dce/rpc server framework
[i.e. freedce].

as it is, instead, you've probably being attempting
to deal with this "problem" for months, and haven't
realised what the real underlying cause is [your own
lack of understanding of dce/rpc issues].





a better example.  if you absolutely _must_ give a different
user [or machine, or group: whatever] a differently configured
setup, then you have an "loadparam hook" which, whenever a
reload_services() changes, a program can be called, with %X
%Y %Z options on its command-line.

in this way, a daemon may be fired off that will listen in a
different location, i dunno...  it sets up a unix-domain-socket
in a different place, or it uses a different area of
shared-memory, to deal with that user (%U) or that unix group
(%G) or that client machine (%m).

whatever.

there are ways and means.


> > > of loadable module support) then it might be possible to work closer on
> > > the RPC server end of things.
> > 
> >  loadable module support is _not_ the way to do it.
> > 
> >  "controlled" from HEAD is not the way to do it.
> > 
> >  no sane dce/rpc programmer wants their namespace polluted
> >  by samba function namespace [there are technical ways to
> >  deal with this, if you can be bothered].
> 
> So, why can't such a loadable module then call your named-pipe interface
> (which is what I'm assuming this is all about)?
 
 there is no reason why that should not be done.

 however, you must ask andrew or jeremy or basically someone
 who is _not me_ to implement it.

 why?

 because a) your friends have no trust in anything i write, and
 have a pavlov's dog psychological knee-jerk reaction [that they
 still haven't dealt with] that automatically rejects anything that
 i say, write or do.

 because b) i have no time, money or resources available at my
 disposal any more to do any development AT ALL of ANY open source
 projects.

 i'll put it bluntly: if you or anyone else particularly want to
 see this happen, give me money.  no money up-front, no work done.

 that's now the way things are.
 
 i've been ripped off and jerked around enough times over the
 last three years, and had enough of it.

 lkcl