RpcImpersonateNamedPipeClient

[Nicolas Williams]

On Thu, 10 Feb 2000, Luke Kenneth Casson Leighton:
> hi seiichi! i'm really glad to hear from you on this issue. 
> 
> On Wed, 9 Feb 2000, Seiichi Tatsukawa wrote: 
> 
> > | i think i have a possible reason why microsoft implements DCE/RPC 
> > | daemons as the SYSTEM cotnext (whatever) and only calls RpcImpNPC 
> > | if needed. it's because the implementation of this call takes TOO 
> > | DAMN LONG on nt to be called for every single function call. 
> > 
> > Look, DCE/RPC was developed on the operating system which had no native 
> > thread support, thus no security context per thread. That system "Unix" 
> > had (still has) the process-wide security context only. DCE/RPC server 
> > runtime was multi-threaded, but the client security context (delegation 
> > and impersonation), obtained by rpc_binding_inq_auth_caller() (or 
> > rpc_binding_inq_auth_client()), was only used by DCE APIs, not by Unix's 
> > native APIs (e.g., file-system access, etc.). 
> > 
> 
> oo... ok, so... dce api server application writers chose to implement 
> their own security context? (not dce/rpc itself, that's different). 

Yes. That's what I've been saying. Different MSRPC daemons will act
differently with respect to the callers security context. It's upto
each service's design and each implementation.

> > It's up to the server application writer to decide whether to use the 
> > client context or not. MSRPC simply follows this model. (Obviously, MSRPC 
> > has better integration with OS because Win32 APIs can use the client 
> > security context once the server thread impersonates the client.) 
> 
> starting to understand. 

:)

> thanks. 
> 

Nico
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.