lsarpcd

[Luke Kenneth Casson Leighton]

On Tue, 14 Dec 1999, Andrew Tridgell wrote:

> > i cut/paste smbd as the basis for the daemon-starter, therefore in exactly
> > the same way that smbd self-spawns for incoming SMB connections, the
> > individual msrpc daemons self-spawn for incoming MSRPC connections, and
> > terminate in the same way.
> 
> Luke,
> 
> I don't think we've yet seen a reason from you on why this stuff
> should be in separate daemons,

i can't justify it in anything that resembles "practical" reasons or
reasoning.  please trust me for now, and if there's no reason _not_ to
run with separate daemons.

plus, what's the big deal?  if you have to split it at all into one
daemon, what's the issue with splitting it into several?

> and we certainly haven't seen a reason
> why it should be fork-per-request.

i will be architecting a single-process arrangement and a fork-per-request
one.  however, that assumes that the single-process is reliable.  crash
one, you crash 'em all.  that why we fork in smbd.

andrew, the one thing that really surprises me is that all the reasons
that apply (security, for-per-req) as to why smbd is architected the way
it is also apply to msrpc, and you think that they do not apply to msrpc
services.

i am genuinely mystified.
 
> The only good reasons for this whole change so far have been:
> 
> - to allow you to develop separately, because we find it hard to
>   co-exist in the same code tree (our development methodologies are so
>   different) 
> - to allow msrpc to run over different transports.

yep.

> the above two reason suggests a single msrpc daemon that is long lived
> and handles all rpc requests. 

yes they do.

that doesn't mean that a multiple msrpc daemon approach is invalid just
because a single msrpc daemon approach also satisfies this criteria.

 
> > the amount of time that an average MSRPC daemon is up and servicing
> > requests is of the order of... let's take a look at a netmon trace...
> > srvsvcd will be up for 9ms to service a NetrShareEnum.  lsarpcd will be up
> > for 16ms to service an LSaOpenPolicy / LookupSidss / LsaClose sequence.
> 
> I don't see anyone suggesting we have a separate process for strcpy(),
> why do we have a separate process for this stuff???

well, has anyone implemented strcpy() in msrpc?  no, because no-one thinks
that strcpy is a good idea to run locally / over-a-network.

strcpy() is a good function to use on a local system, in a single process.

 
> the caller has to block waiting for the reply, the reply is guaranteed
> not to block, it is short lived, it doesn't require a separate
> security context and it doesn't need any special environment. That all
> screams "library call". 

you should know that i consider the entire msrpc client-side code to be a
special form of "library call" that satisfies slightly different critera:
requires same or maybe a different security context, may run seamlessly
remote or local.  caller blocks, etc.

> Why the hell fork a process? That just makes the whole thing hugely
> more complex!

not hugely, at all.  what makes you think so?

  are you going to recommend that smbd no longer fork a separate process
because it's now, after having been running like that since its inception,
suddenly higely more complex?

more complex than what?

running as a single process?

have you examined nmb-agent and smb-agent?  these run as a single process,
and they maintain a dynamic array of sockets.  lib/vagent.c is 242 lines
of code, and utils/nmb-agent is 295 lines of code.

this is more complex than a simple fork(), which tends to lend a small
weight (very small :) _against_ your argument that a fork() is hugely more
complex.

so, again, what is it that you envisage is so much more complex than doing
a fork()?

by the way, all the msrpc code is at user-inter-face speed, so the
overhead of a fork() is, while not "required", can be justified, in terms
of the robustness and separateion from other msrpc calls it provides.
 
> > >  Could not one daemon autospawn the required NT daemons on demand?
> > 
> > i don't see why not, however this would be best done in a startup script,
> > don't you think?
> 
> I want to know why these daemons are *required* first.

they are not "required" in any way, shape or form, other than attempting
to split smbd at the entire msrpc layer is actually slightly more complex,
coding-wise, than splitting at the msrpc-service layer.

i have chosen to have smbd open connections to an MSRPC service, construct
msrpc PDUs from SMB traffic, feed it over a connection to the MSRPC
service, receive PDUs, and then construct SMB responses from the PDU data.

farming out the entire SMB / MSRPC data to a separate msrpc daemon will
require the creation of some sort of API that can handle the following
commands:

- initiate MSRPC service

- send PDU

- recveive PDU

- terminate MSRPC service.

and i cannot be bothered, at this time, to write such an API, when it's
far simpler to make local function calls:

- fd = open("/tmp/.msrpc/lsarpcd")

- write(fd,smb_pdu)

- read(fd, rsmb_pdu)

- close(fd);

of course, i need to maintain state on where in the pdu the SMB read,
write or SMBtrans has currently got up to, and that is absolutely no
problem.  far less of a problem than sub-dividing the entire MSRPC
processing off down a socket and requiring an API to do it, but i haven't
ruled out doing this at some point: i do quite like it.


andrew, i'd really appreciate it if you could trust my judgement on some
of these implementation issues.  reasons such as "we don't need it now"
and "it doesn't fit all the requirements that we need right now" are not
enough to make me pull the plug on an implementation, and replace it with
one that does effectively the same job but has certain architectural
limitations.

if i choose to do something, it's usually going to fulfil the current
requirements _and_ fulfil some other requirements that i haven't even
_thought_ of, yet.  and if it didn't result in some aditional flexibility,
or solve some serious or just some three-year-old problem that's been
botherhing me for so lo,g i wouldn't bother doing it in the first place,
it would be next year's problem.

so please, trust me that i can intuitively tell what's goiing to happen at
some point in the future, which is driving some (not all) of the design
decisions i make, and i can't really explain it because we're not _in_ the
future, yet!

thx,

luke