Mailing-List:	contact cygwin-developers-help AT cygwin DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-developers-subscribe AT cygwin DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin-developers/>
List-Post:	<mailto:cygwin-developers AT cygwin DOT com>
List-Help:	<mailto:cygwin-developers-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender:	cygwin-developers-owner AT cygwin DOT com
Delivered-To:	mailing list cygwin-developers AT cygwin DOT com
Date:	Mon, 5 Aug 2002 14:14:50 +0400
From:	egor duda <deo AT logos-m DOT ru>
Reply-To:	egor duda <cygwin-developers AT cygwin DOT com>
Organization:	deo
X-Priority:	3 (Normal)
Message-ID:	<61668562061.20020805141450@logos-m.ru>
To:	cygwin-developers AT cygwin DOT com
Subject:	Re: 1.3.13?
In-Reply-To:	<20020804195150.GA3381@redhat.com>
References:	<20020804195150 DOT GA3381 AT redhat DOT com>
MIME-Version:	1.0

Hi!

Sunday, 04 August, 2002 Christopher Faylor cgf AT redhat DOT com wrote:

CF> I'd like to release 1.3.13.  The outstanding issues that I am aware of
CF> are Conrad's UNIX domain socket patch

I'm looking at it. The problem this patch addresses it valid. The
way to solve it looks correct too, but i have one reservation.
It turned out that original method to provide security via creating
event object with secret name doesn't really provide security :(
I found several days ago that the namespace which contains events,
semaphores and other kernel objects can be listed by non-privileged
local user. That is, we can't, unfortunately, to rely on secrecy of
object name. The obvious way to fix this with current approach is to
add appropriate security information to handshake events so that
non-privileged process won't be able to signal them. With Conrad's
approach, as far as i understand, handshake relies on mere existence
of needed object, so i don't know how to protect communications in
this case.

Egor.            mailto:deo AT logos-m DOT ru ICQ 5165414 FidoNet 2:5020/496.19

- Raw text -