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_seacces...
... 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.