dce/rpc "client" api

[Luke Kenneth Casson Leighton]

On Tue, 22 Aug 2000, Andrew Tridgell wrote:

> > it is also _not_ a new protocol.  it's a transport. it does absolutely
> > _nothing_ - zero modifications - to the Dce/rpc data it transports.  it
> > therefore has no effect on any code reviews required of the marshalling /
> > unmarshalling, zero effect on any code reviews required of the dce/rpc
> > service implementations.
> 
> There is a bit more to communicating with pipe daemons than just
> passing along pdu data. You also need to pass along (and potentially
> pass back) state information about smbd.  The involves some sort of
> protocol.

if you choose to call it a protocol, then the simplest of these protocols
is to read the smb.conf file.

i agree that this particular issue is a tricky one.  in and of itself,
_regardless_ of the implementation, _any_ implementation of dce/rpc
services shows up very specific weaknesses and problems, or more
specifically problems through the _use_ of, using smb.conf and the
"substitution" system.

a very clear example that became an immediate problem - i.e. after less
than 6 weeks of dce/rpc development - was the use of \\%L\U% in
lp_logon_path() in netlogond.

i had to add a horrible, temporary hack to deal with this
[sam_logon_in_ssb boolean], that has remained in production code for well
over two years, now.

the problem is that the smb.conf for IPC$ over which \PIPE\netlogon is
made is anonymous, i.e %U is totally meaningless when it comes to
substituting that as the username for the generation of the user-profile
in the NetrSamLogon response.

this problem has been surmounted in TNG [ in a not entirely satisfactory
manner] by introducing standard_sub_vuser().  there are three levels of
substitution [two in HEAD]:

standard_sub_basic()

standard_sub_vuser()

standard_sub()

the one missing from HEAD is standard_sub_vuser().