Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , 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 Reply-To: egor duda 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 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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