SAMBA_TNG status report and design discussion.

[Luke Kenneth Casson Leighton]

just added some code that i've been meaning to add for a long, long time.
SMBwriteX usage / processing in rpcclient and smbd, respectively.

multiple PDUs can be handled EITHER through SMBtrans+SMBtranssecondary OR
SMBwriteXs.  i sent details on how to do SMBwriteX to samba-cvs on the
commit message, if you're interested.  DO NOT get the implementation of
this wrong, client-side.

i altered the way that data is transferred between smbd and dce/rpc
daemons.  i was previously using a NetBIOS session format to transfer data
over the unix socket.  i didn't like this, so removed the NetBIOS header
and just send the data.  now, the dce/rpc daemons must parse the dce/rpc
header isntead of a NetBIOS header.

i was _going_ to remove the DCE/RPC header parsing in smbd, but instead i
had to add to it.  see samba-cvs commit message for details.

removing the NetBIOS session format and using straight dce/rpc format
instead should mean that the implementation of dce/rpc over TCP will be
_really_ simple: feed TCP data to unix socket; feed unix socket data to
TCP.  no messing about.  _hopefully_ there shouldn't need to be any
parsing of the DCE/RPC header, just a select / read-write detector.  samba
currently only has a select data-detector, it doesn't distinguish between
read and write because we never needed it before.  SMBs are _always_
interspersed, read / write.  you _never_ get an SMB request followed by an
SMB request follwowed by and SMB response, like you can with dce/rpc.
req, req, req, resp, resp, resp, resp, req, resp, req, resp, resp etc.

next stage is to fix authenticated-dce/rpc, which i know is broken.  this
means password changing, basically.

after that, i start to remove all the direct smbpasswd access code, and
use \PIPE\samr equivalents instead.  if i can find any other stuff that
does the same kind of thing (for example, i _may_ consider rewriting the
SMB print stuff in smbd as \PIPE\spoolss calls, in 6 months or so when
i've written a proper set of spoolss rpcclient commands) then i will
tackle that, too.  i basically want smbd to be as thin as possible, and
ONLY dealing with file sharing.  if it's not files, it's not smbd's
business.  oh yes, of course: NetrShareEnum in smbd/ipc.c etc.  all of
those can be implemented as \PIPE\srvsvc and/or \PIPE\wkssvc, i almost
forgot :-)

of course, this assumes quite a lot.  the assumption is that it's ok to do
NetrShareEnum (actually srv_net_srv_share_enum() in
rpc_client/cli_srvsvc.c) from in smbd/ipc.c, etc.

the implications are:

- that a loop-back onto a unix socket is acceptable.

- that the consequences of doing a dce/rpc call are acceptable,
particularly as the current implementation fires up a new daemon each
time.

- that a dependency on dce/rpc daemons is acceptable.  at present, if you
wish to operate in security = share or even security=user+encrypted
passwords = no you a)can't use the msrpc daemons for security b) don't
_need_ the msrpc daemons for security.

you _also_ don't really need \PIPE\srvsvc.  if you don't run it, samba
will fall back to pre-1.9.17 behaviour.  actually, that's probably not
true.  i think even pre-1.9.17 had a "mini" \PIPE\srvsvc decoder that did
a byte-by-byte NetrServerGetInfo and a stub NetrShareEnum as this
_drastically_ altered (and stabilised) the behaviour of nt clients, as
NT-to-NT gets radically more testing inside microsoft than NT-to-nonNT
(excluding 95-to-NT and NT-to-95, of course, because i couldn't care one
bit about 95).

the line of reasoning i am following, here, is based on a conversation i
had with andrew, three weeks ago.  andrew doesn't want smbd to be
dependent on _any_ msrpc services.  i agree with him.

i am thinkin, however, that there may be one critical dependent msrpc
service: \PIPE\srvsvc, specifically NetShareEnum and NetServerGetInfo.  if
you don't have those, NT clients assume that they are NOT talking to an NT
server, and LOTS of other neat stuff, such as NT-style password changes
and the behaviour and use of some of the file-access SMBs goes out the
window.

therefore, if we _must_ have \PIPE\srvsvc, then srvsvcd (or, as andrew
would like, \PIPE\srvsvc running inside msrpcd, which i haven't got round
to doing / thinking about yet, other than at a specification level, sorry
andrew) _must_ be running.

if srvsvcd is always running, then it's ok to have smbd/ipc.c's
api_RNetShareEnum and api_RNetServerGetInfo etc implemented as calls to
srv_net_share_enum() and srv_net_srv_get_info() etc.

problem with that, is, that if you're _not_ running srvsvcd, you don't get
_any_ netshareenum / netservergetinfo etc.

which brings me on to _another_ alternative implementation that andrew and
i were discussing three weeks ago, which would be to have
srv_net_share_enum() and srv_net_srv_get_info() as dynamically loadable
.so functions, and they get loaded up inside smbd.  this kinda breaks the
dependency thing i was really hoping to aim for [to have smbd as JUST file
serving and NOTHING else], but we may have no choice.  i recognise that,
realise that it may not be practical, so i'm not going to be an idiot and
insist.  i'm still going to try and implement it, mind, just to see how
far it gets me :-) :-)

comments, anyone?