Mail Archives: cygwin-developers/2002/01/04/02:10:43
----- Original Message -----
From: "Gary R. Van Sickle" <g DOT r DOT vansickle AT worldnet DOT att DOT net>
> You can, and I will, but I think I should address this security issue
with mutt
> first and reroll it. Hopefully I can get that done yet tonight, but
you know
> how things go....
For sure :}.
> What exactly would you like me and others to test/evaluate? From your
post
> previous to the above:
>
> "Also the code is in two distinct chunks:
> 1) A daemon to run under NT and 9x and provide cross-process services
to
> cygwin.
Does this chunk look like a reasonable implementation. Does cygwin start
playing up/die badly. Are there any significant issues that *you* think
would stop the release of (say) cygwin 1.7 with the daemon as-is.
> 2) A security fix which Egor created the original daemon to accomplish
> when passing tty handles around,
Does this work well.
> and an IPC- SHM only just now -
> implementation using the daemon, which has been used by me to push the
> daemon limits..."
Ignore this bit (or optionally provide feedback, but it's known to be
incomplete).
> Now without IPC, are we talking about process-related things that
already exist
> but are implemented without a third process managing them, e.g. mmap,
fork, etc?
At the moment, the only changes in-dll are:
at process startup a test call is made to the daemon.
IPC calls can go via the daemon.
TTY handle transition is done via the dameon.
So nothing else should be affected. IOW IMO there is precious little to
check :}.
I still have trouble with make check, so if that works for you knowing
whether the daemon behaves any worse would be useful.
To get the daemon, cd to winsup/cygwin and run
cvs -z3 update -Pdr cygwin_daemon
(make sure you commit, generate a diff of anything in your sandbox).
Rob
- Raw text -