evaluation of using freedce project in Wine [was: compiling test.idl with dceidl - bit lairy and archaic]

[Luke Kenneth Casson Leighton]

On Wed, Jan 19, 2005 at 06:17:35PM -0600, Robert Shearman wrote:

> That's certainly one way of doing it. I only worry about Microsoft-only 
> extensions made to the API. 

 hah. 

> For example, RpcServerRegisterIfEx and 
> RpcServerRegisterIf2 (these are probably be the most commonly used 
> extensions). Information can be found about them on MSDN.

 [burblburbl... google.com?search=RpcServerRegiserIfEx...]

	MaxCalls - number of simultaneous rpc calls allowed.

 that: either ignore it, or make it be the number of threads
 that the server runs, i should imagine.  number of threads is
 at present a command-line option (default is 10) so there's
 a hook in there somewhere.

 *shrug*.  dunno.  looks trivial and harmless enough.

 	IfCallback - security call-back
 
 _security_ callback????

	 "Specifying a security-callback function allows the
	 server application to restrict access to its interfaces
	 on a per-client basis."

 oh.  is that all?
 
 if that's _all_ it is, that'd be pretty easy to do.
 	
> How easy would it be to add extensions like this to the FreeDCE project?

 on a case-by-case basis, i'd imagine it to be pretty straightforward,
 if RpcServerRegisterIf2 is anything to go by.


> How easy would it be to add support for client impersonation 
> (RpcImpersonateClient, RpcRevertToSelf)? 

 ah.  my faavvvooourite functions, those.

 *deep breath*.  are you ready for this?

 answer 1)

	 that's where you'd need the cooperation of samba / samba tng:
	 it's got "SIDs" behind it, and "SIDs" means a SAMR server
	 and a NETLOGON server and an LSARPC server (and in the
	 case of windows 2000 interoperability, access to an Active
	 Directory Server).

	 otherwise, the security contexts are of absolutely no use to you,
	 and you might as well implement those as "stub" functions.

	 
	 ... and by a _complete_ coincidence, the samba / samba tng
	 project _happens_ to contain an implementation of DCE/RPC
	 services :)  badly / painfully, as it turns out, because the
	 entire rpc services of both projects are hand-crafted, and
	 are in desperate need of being rewritten, but as they "work"
	 and are "behind" well-defined interfaces, it's _not_ critical
	 that this happen.

	 ... see, it all hangs together around DCE/RPC :)

	 okay: i should be more specific: "_all_" you need is
	 the means to authenticate against an NT PDC (NETLOGON),
	 and to store the credentials returned [a NET_USER_INFO_3
	 structure]

	 realistically, however, that means you need to be able to
	 "join" your Wine Workstation (or ReactOS server) to an NT
	 Domain... and _that_ means you need, for NT 3.5 / 4.0
	 support, a samr server, lsarpc server and netlogon server,
	 and for NT 5.0 (aka 2000), Active Directory kerberos
	 client-side code (modified to overload the PAC to get your
	 NET_USER_INFO_9000999 structure which contains your
	 credentials) and also a netlogon server _and_ an lsarpc
	 server...


 answer 2)

 	see the following:

	http://viewcvs.samba-tng.org/cgi-bin/viewcvs.cgi/tng/source/lib/util_seaccess.c

	... does it look familiar at all? *grin*.

	in particular, take a close look at se_access_check.

	in samba tng, we pass around an NT_USER_TOKEN which is
	constructed from the NET_USER_INFO_3 response which is received
	over-the-wire from a ncacn_np "\\pipe\netlogon" server.

	the RpcImpersonateClient function is a sort-of kludge to
	communicate wire-level stuff which yo u would normally, in
	DCE/RPC land, enforce yourself, by calling SeAccessCheck,
	into the NT Kernel, where, as i understand it, the kernel
	then starts believing that the thread is running with a user
	context (as handed to it by RpcImpersonateClient).

	presumably - and i can only guess at this where other people
	will know better - the RpcImpersonateClient function turns
	information it receives from DCE/RPC land into the equivalent of
	"setuid" for NT.

	so, it's a _long_ story, where i've seen all the bits, but never
	encountered a situation in which it has been necessary to
	_actually_ hang them all together.

  answer 3) - the summary.

  	it's doable, very doable - but you would likely need to
	port samba or samba tng's samr, netlogon and lsarpc services
	into ReactOS in order for the RpcImpersonateClient tokens
	to actually _mean_ anything.
 
    and with _that_ in mind, perhaps people will at least
    begin to appreciate why i've been smashing my head
    against a xxxing brick wall with the samba team trying
    to get this point across to them - namely that the samba
    project is only _one_ small part of an insanely large
    multi-million-lines-of-code undertaking, spread out across
    and impacting at least ... five major free software projects
    that i can think of.


> These functions will be 
> important for other projects using our code to run services in 
> privileged processes (namely, the ReactOS project).

 yessss :)  i was so pleased to hear about that project.

 
> You are starting to convince me that there is some potential for FreeDCE 
> in Wine.
 
 gosh.  *scratches head*.

 hopefully, the answer above won't put you off too much!

 :)

 you can always still implement RpcImpersonateClient as a stub.

 but remember, Elrond is already working with the ReactOS
 developers, as the ethos of Samba TNG is to _cooperate_ with
 and _accommodate_ other projects, to simplify development by
 keeping individual components to manageable sizes, emphasise
 the interfaces, and generally make it easier for developers
 to understand what is going on.

 so, whilst you might at first quail and quake at the scope of
 the undertaking i've outlined / gone-on-at-length-about caused
 by that one simple question [ :) ] i think you'll find that
 the pieces are already there, the people vaguely already know
 what's going on, and it's almost a matter of lining everyone
 up in the right direction at an appropriate time and saying "Go!".

 no - "go" not "boo".

 teehee.

 l.