This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: CYGWIN SERVER: Some questions


On Mon, Sep 03, 2001 at 08:53:57PM -0400, Christopher Faylor wrote:
> On Mon, Sep 03, 2001 at 11:51:16PM +0200, Corinna Vinschen wrote:
> >On Mon, Sep 03, 2001 at 03:55:26PM -0400, Christopher Faylor wrote:
> >> On Mon, Sep 03, 2001 at 05:42:51PM +0200, Corinna Vinschen wrote:
> >> >> How about mailboxes as the communication mechanism?  They share many
> >> >> of the characteristics of named pipes, I believe but *I think* they
> >> >> work on Windows 95.
> >> >
> >> >I'm not quite sure about the seriousness of this mail but if you
> >> >refer to mailslots... they are just a one-way mechanism to push
> >> >some data to another process. No real `communication' at all.
> >> 
> >> Oops.  Yes, I meant mail slots.  They are one directional, but so are
> >> pipes.  You just open one mail slot for each direction.  Or, you use it
> >> to synchronize a shared memory region.
> >
> >Named pipes under NT can be bidirectional by giving the
> >PIPE_ACCESS_DUPLEX flag in call to CreateNamedPipe().
> 
> But we can't use named pipes.

We can use them on NT only and use another TL on 9x/ME if we
actually implement different TLs.  I don't think that makes sense
in the beginning, though.  I would prefer a single mechanism
which works for all systems and which has the additional security
thingy for NT for the first implementation.

> >Mailslots have no security mechanism so they wouldn't be the
> >TL I would choose for NT/W2K/XP.
> 
> Don't mail slots have the same security mechanism as files?

Yes but that's not what I'm talking about.  I'm talking about
changing user context on behalf of the client which is a very
important security feature.  That's NT only of course: The
server is running under LocalSystem account so it's MIGHTY!
But it shouldn't.  Under 99% of the conditions it would be
appropriate to run in the user context the client is running
in.  Especially if the server tries to change ownership of
objects and such stuff, it should have the access rights of
client only.  At least it should _know_ these rights.

We _could_ do that by sending user information inside of
our HL protocol but that's not `security' since that could
be faked by a malicious client.

So, the protocols which support that already on the Win32 API
level are:

- Named Pipes:	ImpersonateNamedPipeClient()
- DDE:		DdeImpersonateClient(), ImpersonateDdeClientWindow()
- RPC:		RpcImpersonateClient()
- COM:		IServerSecurity and IClientSecurity Interface.

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]