From owner-cvs-src@FreeBSD.ORG  Sun Feb 13 17:39:55 2005
Return-Path: <owner-cvs-src@FreeBSD.ORG>
Delivered-To: cvs-src@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id 1678C16A4CE; Sun, 13 Feb 2005 17:39:55 +0000 (GMT)
Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id D273A43D5A; Sun, 13 Feb 2005 17:39:54 +0000 (GMT)
	(envelope-from robert@fledge.watson.org)
Received: from fledge.watson.org (fledge.watson.org [204.156.12.50])
	by cyrus.watson.org (Postfix) with SMTP id 55A5346B0D;
	Sun, 13 Feb 2005 12:39:54 -0500 (EST)
Date: Sun, 13 Feb 2005 17:38:39 +0000 (GMT)
From: Robert Watson <rwatson@FreeBSD.org>
X-Sender: robert@fledge.watson.org
To: Maxim Sobolev <sobomax@FreeBSD.org>
In-Reply-To: <200502131737.j1DHbKaM017082@repoman.freebsd.org>
Message-ID: <Pine.NEB.3.96L.1050213173708.43822B-100000@fledge.watson.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
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-src@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: CVS commit messages for the src tree <cvs-src.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>,
	<mailto:cvs-src-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/cvs-src>
List-Post: <mailto:cvs-src@freebsd.org>
List-Help: <mailto:cvs-src-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>,
	<mailto:cvs-src-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 13 Feb 2005 17:39:55 -0000


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. 

Robert N M Watson