From owner-cvs-all@FreeBSD.ORG Sun Feb 13 18:00:05 2005 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A82E16A4CE; Sun, 13 Feb 2005 18:00:05 +0000 (GMT) Received: from www.portaone.com (support.portaone.com [195.70.151.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E4DB43D53; Sun, 13 Feb 2005 18:00:04 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from [192.168.1.26] (SIRIUS-ats227-UTC.ukrtel.net [195.5.25.154]) (authenticated bits=0) by www.portaone.com (8.12.11/8.12.11) with ESMTP id j1DHxG7S087791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 13 Feb 2005 18:59:17 +0100 (CET) (envelope-from sobomax@portaone.com) Message-ID: <420F956B.2080804@portaone.com> Date: Sun, 13 Feb 2005 19:59:07 +0200 From: Maxim Sobolev Organization: Porta Software Ltd User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/685/Wed Jan 26 10:08:24 2005 clamav-milter version 0.80j on www.portaone.com X-Virus-Status: Clean cc: cvs-src@FreeBSD.ORG cc: src-committers@FreeBSD.ORG cc: cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/i386/ibcs2 ibcs2_signal.c src/sys/kern kern_prot.c kern_sig.c src/sys/compat/linux linux_signal.c src/sys/compat/svr4 svr4_signal.c src/sys/sys proc.h syscallsubr.h src/sys/alpha/osf1 osf1_signal.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2005 18:00:05 -0000 Robert Watson wrote: > On Sun, 13 Feb 2005, Maxim Sobolev wrote: > > >> Backout previous change (disabling of security checks for signals delivered >> in emulation layers), since it appears to be too broad. >> >> Requested by: rwatson > > > Thanks, and sorry if I was a bit too fierce. This is not the first nit > we've run into with the more conservative signal protections, which is why > there's a sysctl to disable them in the first place. However, I think > they contribute usefully to security, so I'd rather augment them to be a > bit more context-aware and permit what's necessary, while avoiding more > sweeping granting of permission. OK, you have nothing to be sorry about. You have much more knowelledge in this domain than I, so that I really appreciate your review and analysis. -Maxim