Mail Archives: cygwin-developers/2001/04/23/20:15:01
> -----Original Message-----
> From: John Fortin [mailto:fortinj AT attglobal DOT net]
> Sent: Tuesday, April 24, 2001 10:03 AM
> To: Christopher Faylor
> Cc: Robert Collins
> Subject: Re: Looking for something to work on...
>
>
> >
> > I don't remember if I answered this or not but isn't this
> what cygipc
> > provides now?
> >
> > FWIW, I'd love to have an unemcumbered (licensing-wise)
> version of cygpic
> > available.
>
> What is the difficulty with the licensing?
Cygwin source can be exported to GPL but not vice versa.
> >
> > I was discussing this with Corinna today. The current
> version uses a
> daemon
> > to handle the requests, I believe. I think we could get by
> with having
> > cygwin start up a process if one didn't already exist. We
> could try to
> > make the process invulnerable to windows closes and user
> logouts so that
> > the message queues and semaphores would be persistent.
> >
> > This would also be something that could be incorporated into Egor's
> daemon,
> > too, if you've been following the discussion in cygwin-developers.
Yeah, I'd like to see Egors daemon be essentially the persistent
'kernel' part of cygwin. I.e. fd's, memory areas and other things that
win32 will close automatically or needs high security to access can be
got via a request to the daemon. And auto-startup would be good (I
recall suggesting it... but on furhter thought it won't fly on NT).
Autorequesting service to start might work. (It potentially needs access
to all cygwin process's, and will be trusted by all cygwin process's.
Thus it cannot run in the same context as untrusted code or it could
have it's own code overriden maliciously.)
Example of that:
Close all cygwin programs (including the daemon).
Run a 'bad' program that's linked to cygwin.
The bad program will cause (via cygwin1.dll) the daemon to start. But
the bad program has the returned handle to the daemon in it's address
space (via cygwin1.dll).
The bad program then writes into the address space of the daemon and
quits.
Because the daemon doesn't shutdown, every subsequent login will use the
now-compromised daemon. In fact the bad program could even just launch
bash.
> I saw some general discussion, but I never quite got the jist
> of what the
> daemon did..
Prevents brute force attacks across process boundarys due to win32 API
holes.
> I saw that Robert Collins had been doing some investigating
> into the ipc
> stuff. Do you know what his current status is...
It's going. Works ok. I've paused development until the daemon is
present (no point in reinventing the wheel). I haven't done all of the
features, so far just shm, but that only took a couple of hours to get
passing test suites and most of that was my pshared mutex support.
Rob
- Raw text -