outsourcing DCE/RPC to alternate programs - runtime config option

[Luke Kenneth Casson Leighton]

On Mon, Dec 13, 2004 at 11:32:29PM +1100, tridge at samba.org wrote:
> Luke,
> 
>  > > I don't consider that much of a problem at all - what is the issue with
>  > > implementing 3 interfaces in one daemon? 
>  > 
>  >  it's just a design decision that i would consider to be closing down a
>  >  few strategic options (hinted at below)
> 
> You've been going on about this "all separate daemons" idea for far
> too many years. Did you actually ever check that windows does
> implement them all as separate daemons? 

 yes: the hint is from the response of the rpc bind ack packet: the name
 of the server that is actually handling the pipe is put in the
 response.


> It doesn't.
 
  yes, i know.

  i didn't consider it relevant: i made a design decision and decided to
  stick with it, in order to help me code up and real-world test the
  client and server side implementations of what became netlogond, samrd
  and lsarpcd.

  as a result of that design decision, i was far more
  confident of the robustness of the three services, the
  ncalrpc implementation, and the client-side functions.

  such that i could then advocate other projects.

  i have not mentioned before (explicitly) that it occurred
  to me many many times as i got rather pissed off and frustrated with
  the "separation" process i had undertaken, giving serious
  consideration to bypassing the ncalrpc interface i was creating, and
  linking one big monster program combining the three services - exactly
  as you say.

  the reasons why i _didn't_ do that were primarily because
  of samrd: if i _had_ done one big monster authentication
  program, it would have meant more code for anyone
  wishing to implement samrldapd, samrsqld or samrtdbd, or
  sam-whatever-somebody-other-than-me-chose-d.


  also, i believe that if you analyse NT 3.5 i expect you'll find that
  there, the three services _are_ separate (or at least two of them).

 
  anyway: the point is that just because NT implements three
  services in one daemon, that isn't a good enough reason
  to terminate any _possibility_ for implementing three
  protected/authenticated services in separate daemons, and
  it certainly isn't a good enough reason to justify _not_ adding
  security-context-inheritance to ncalrpc.

  however, i realise that it's entirely up to you: should
  you choose to implement those three closely inter-related
  services in one daemon, that's your design decision, and one
  of the major technical justifications for doing sec-ctx-inh
  in ncalrpc goes away.

  if there were other projects - real-world examples - that
  needed it, [and i'm sorry to have to point out that because
  you have delayed adding ncacn_np "outsourcing" in samba for
  over five years there _aren't_ any such examples] ...




> As for your comments about posix and NTFS, if you'd actually followed
> the development we've been doing for the last few years then you'd
> know that we already use nt-like file sharing interfaces internally,
> and have had discussions with the Linux ntfs people about working
> together. You would also know that Samba4 is almost completely
> independent of posix, except for 8k lines of "glue" code that
> implements the posix backend.

 GREAT.

 that's fantastic.

 i'm genuinely pleased.

 it's such a far cry from the "samba is just a file and
 print sharer" argument which jeremy used in 1999 to stop me
 advocating improvements to samba 3's smb vfs layer.



> If your only contribution is "wise words" based on 4 year old
> information then please just go away.
 
 andrew, listen to yourself.  please calm down.

 l.

-- 
--
<a href="http://lkcl.net">http://lkcl.net</a>
--