[ros-dev] Re: proper nt-style authentication (reactos, wine, samba tng)

[Luke Kenneth Casson Leighton]

hi, rob, thanks for responding.

On Fri, Sep 02, 2005 at 12:05:24AM -0500, Robert Shearman wrote:
> Luke Kenneth Casson Leighton wrote:
 
> >that you - the wine team - continue to reinvent an non-interoperable
> >version of MSRPC, for binary-level "DCOM" interoperabiltiy ONLY,
> >demonstrates quite how just as bloody stupid you are being.  that _can_
> >be taken as a compliment, as i genuinely i mean it with the greatest of
> >respect.
> > 
> >
> 
> Ok, I want to condense your huge message into a numbered list of things 
> you say we need:

 wheeeeee :)

> 1. Type marshaling.
> 2. IDL compiler.
> 3. RPC Server.

 more specifically, rpc server "infrastructure" from which to develop,
 create, compile run and support RPC servic_es_.

 this you gain in the quickest possible way from FreeDCE and in the
 grungiest possible way from either samba or samba tng.

 
> 4. Authentication.
> 5. Services (lsa, netlogon, samr, etc).

 yep.

> Ok, so we are we at with Wine and ReactOS?
> 1: We need to implement this anyway because, like you crudely put it, we 
> are in the crazy business of getting real code like InstallShield and 
> Office 2003 to work.

 muhahahahah.  hey, Security-Enhanced ReactOS, anyone? :)


> 2. We can either use MIDL and accept the problems that go with it (like 
> not generating code that will compile with gcc 4.0) or we can finish 
> implementing proxy support in widl.

 okay.

 the amount of effort required to modify dceidl to support
 binary-interoperability with MIDL i do not believe to be very large,
 but the key bit which _will_ take some expertise (i.e. there are better
 people than myself to do the job) is the adding of Win32 threading
 model support to FreeDCE.

 going down THIS path will GET you code that will compile with gcc 4.0
 (and mingw32) AND it would be binary interoperable with MIDL.

 AND it would actually work, without having to reimplement type
 marshalling, which if you look at FreeDCE's marshalling/unmarshalling
 code is SEVENTY THOUSAND LINES of immensely complex code.


> 3. We have support for named pipes in the RPC server, 

 what is the "RPC server"?  i do not know of such a beast :)

> but Wine doesn't 
> support remote named pipes and AFAIK ReactOS doesn't either. This is not 
> a problem that should be solved by the RPC runtime.

 no.  it has nothing to do with the RPC runtime.

 you write a plugin that implements thirty or so functions (which have
 names like open, write, close etc. funnily enough :) and then register
 it with the RPC subsystem (yeh, okay, probably the rpc runtime :)

 e.g. the named pipe transport is called ncacn_np - network computing
 architecture CoNnection-based named pipes.

 and then MSRPC clients and MSRPC services can simply utilise that
 transport automatically or by name.

> 4. Kai and Juan are working on delegating NTLM authentication to Samba. 

 ah.  brilliant.  that's exactly what i outlined as "stage 1" and it
 should be done by implementing MSV1_0.DLL, for use by LSASS, see
 LsaLogonUser in the ntoskrnl code, it's a stub at the moment, in the
 reactos code.


> We still need to tie this in to the RPC server though. 

 i do not know what you mean by the "RPC server".  no such entity
 actually exists afaik.

> That should be a trivial task in comparison. 

 yes, which is why it is mentioned about 2/3 of the way through my
 document, as "stage 1".

> Not sure how this will fit in on ReactOS.

 in NTOSKRNL the LSASS implementation, which then has MSV1_0.DLL
 register with it.  i mentioned it in my document.

 see the two occurrences of LsaLogonUser in reactos code.


> 5. Wine isn't really interested in having those types of servers, 

 tough luck for them.
 
 nt domain services are a necessary and integral part of supporting win32,
 even in a stand-alone environment.

 wine has _bypassed_ the MSRPC bits by instead of utilising MSRPC to
 split client from server they have "linked" the client-side code with
 its server-side code, cutting out the MSRPC runtime altogether.

 due to the incredible way that MSRPC (actually DCE/RPC) is designed, it
 is perfectly feasible to do this sort of thing, and actually have your
 code work (just with no networking and no distributed capability)

 anyway.

 if the wine team cannot be convinced of the necessity of adding
 MSRPC into the mix then wine will pretty much remain in the
 dark ages of interoperability along the lines of "win95 with networking
 removed".


> but it 
> would be nice for the client code for those to work. I'm not sure that 
> porting them from Samba would be fruitful as they would fundamentally 
> need to tie into the registry.

 yes? :)  and? :)

 i have no problem with that.  i'd _love_ to see a registry service
 implemented in samba tng and then utilised in a samrd to access an
 NT SAM hive :)

 it's the way that reactos has gotta go, basically.


> So, what you are suggesting is that we instead port FreeDCE and use it 
> for 1-3 (and 4?). 

 basically and ultimately - yep!

 BUT, butbutbut - remember, i did say that it is _not_ strictly
 necessary at the moment.

 there are ways - and it appears that you are already considering them -
 to cut down the amount of work required to "GetThingsWorking(tm)", as i
 described.


> This while still having to implement (1) anyway 
> because of the applications I mentioned that need it. 

 no, you don't have to.
 
 you hack FreeDCE into interoperability because it IS the
 rpc runtime.

 remember, microsoft adopts code wholesale if they can get away with it.

 they started from DCE 1.1 reference implementation and ported it to NT.

 FreeDCE _is_ the DCE 1.1 reference implementation - autoconf'd and
 modularised.

> Then we get to 
> test two different MSRPC infrastructures and get to fix bugs in one 
> without it fixing any bugs in the other. Just porting FreeDCE seems like 
> a lot of work; 

 okay, the reason why it seems that way is because i actually know
 what's involved and have described to you what's involved.

 if you described to me what you are endeavouring to do in
 reimplementing the rpc runtime, i can give you some time estimates on
 how long it will actually take, and i guarantee you it will make the
 amount of time i've outlined for porting FreeDCE look like a walk in
 the park by comparison.

 that's all.

 remember, i did EXACTLY the same thing.  i looked at the OpenGroup's
 DCE/RPC documentation, and went "christ almighty i can't possibly be
 doing with all this" and ignored it.

 THREE YEARS LATER i was wishing in some ways that i hadn't.

 the learning curve however of doing on-wire interoperability gave me
 enough understanding to appreciate just how good dce/rpc really is, and
 quite how much work is involved.

 you would do well to LISTEN to that advice of someone who wasted three
 years of their life NOT listening to advice, who followed the same path
 as you are following (the not-invented-here path).
 
 it will save you a lot of time.

 you would do well to bite the bullet and utilise your wealth of
 experience and knowledge learned to-date as a means to "tie in" to the
 freedce code.

 you _have_ enough knowledge and expertise now to be able to do that.

 you alone rob have been dealing with rpc type libraries for, what, two
 years now?

 a function-by-function comparison of freedce and wine's rpc runtime
 will show EXACTLY the same functions, EXACTLY the same arguments, and i
 started to show you that some six months ago, remember?

 now there is the reactos project to take into account, too.


 
> perhaps more work than implementing the remaining 
> features in our own MSRPC infrastructure, even when including the task 
> of finishing the IDL compiler. Maybe I am being blind, but it seems to 
> make sense just to carry on in the direction we are going with having 
> our own MSRPC implementation and being able to "dogfood" our 
> implementation (i.e. use it for our own proxies/stubs at the same time 
> as letting applications use it).

 there is an opportunity to save _everybody_ time, right across the
 project board.

 i have said this in 2000 on the samba mailing lists.
 i have said it on that mailing list discussion six months ago on
 the wine-devel lists.
 i am saying it now.

 freedce is the key to interoperability for samba, wine, reactos,
 because it is the same code that microsoft hacked into submission
 to make the services which samba, wine and reactos are independently
 implementing, without proper reference to each other.

 samba is implementing "on-the-wire" interoperability without the
 type-libary interoperability and without the IDL-level and
 runtime-level interoperability.

 wine and reactos are implementing "binary-level" interoperability and
 are avoiding IDL-level and on-wire-level interoperability (by
 suggesting to developers that they utilise MIDL.EXE)

 this is complete madness.
 
 wine will end up with 100,000 lines of hacked-together and
 incomplete code.  samba has two hacked-together projects
 of about 100,000 lines of code each.  samba tng has its
 own hacked-together and equally but differently incomplete
 implementation.

 whereas FreeDCE is 250,000 lines of code that provides IDL-level
 interoperability, on-wire level interoperability, and the things that
 it is missing - win32 threading support, modern (posix) threading
 support and exact byte-for-byte type library interoperability are
 TRIVIAL trivial TRIVIAL computer-science first and second year
 university projects by comparison.

 each time i mention this, the people implementing their own
 non-interoperable projects in their own little worlds get
 deeper and deeper into the shit.

 if i can't convince people that this is the way forward then
 i will simply have to give up and come back in five years
 and see how people are getting on.

 l.


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