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.
