dce/rpc "client" api
Luke Kenneth Casson Leighton
lkcl at samba.org
Tue Aug 22 06:14:10 GMT 2000
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
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
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]:
the one missing from HEAD is standard_sub_vuser().
More information about the samba-technical