From owner-cvs-all@FreeBSD.ORG  Sun Sep 14 08:44:50 2003
Return-Path: <owner-cvs-all@FreeBSD.ORG>
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 0F65516A4BF; Sun, 14 Sep 2003 08:44:50 -0700 (PDT)
Received: from fledge.watson.org (fledge.watson.org [204.156.12.50])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 1DC3C43FEC; Sun, 14 Sep 2003 08:44:49 -0700 (PDT)
	(envelope-from robert@fledge.watson.org)
Received: from fledge.watson.org (localhost [127.0.0.1])
	by fledge.watson.org (8.12.9/8.12.9) with ESMTP id h8EFhWrO019161;
	Sun, 14 Sep 2003 11:43:32 -0400 (EDT)
	(envelope-from robert@fledge.watson.org)
Received: from localhost (robert@localhost)h8EFhWo9019158;
	Sun, 14 Sep 2003 11:43:32 -0400 (EDT)
Date: Sun, 14 Sep 2003 11:43:32 -0400 (EDT)
From: Robert Watson <rwatson@FreeBSD.org>
X-Sender: robert@fledge.watson.org
To: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= <des@des.no>
In-Reply-To: <xzpu17fppjq.fsf@dwp.des.no>
Message-ID: <Pine.NEB.3.96L.1030914113941.19069B-100000@fledge.watson.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
cc: cvs-src@FreeBSD.org
cc: src-committers@FreeBSD.org
cc: cvs-all@FreeBSD.org
Subject: Re: cvs commit: src/sys/kern kern_prot.c
X-BeenThere: cvs-all@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: CVS commit messages for the entire tree <cvs-all.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-all>,
	<mailto:cvs-all-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/cvs-all>
List-Post: <mailto:cvs-all@freebsd.org>
List-Help: <mailto:cvs-all-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-all>,
	<mailto:cvs-all-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 14 Sep 2003 15:44:50 -0000

On Sun, 14 Sep 2003, Dag-Erling Sm=F8rgrav wrote:

> Robert Watson <rwatson@FreeBSD.org> writes:
> >   Also, add SIGALRM to the set of signals permitted to be delivered to
> >   setugid processes by unprivileged subjects.
>=20
> Are you absolutely sure you want to do this?

In the thread, I discussed a few other possible approaches:

(1) Introduce a setugid() API to allow processes to knowingly discard
    additional protections.  This would require application changes.  The
    interface already exists as __setsugid() under options REGRESSION,
    FYI, but I didn't want to leave the knob exposed due to foot-shooting
    potential.

(2) Introduce additional USR signals to be used in lieu of SIGALRM.  This
    also requires an application change.  Actually, I'm not sure I
    explicitly raised this in the thread, but it's the obvious direction:=
=20
    reduce the opportunity for collision between exception signals and IPC
    signals.

That said, to be frank, no, I'm not sure I want to do this.  But I also
want to make sure we don't break important applications.  The answer is
probably to bring the Diablo author and Diablo port maintainer in the loop
and discuss better alternatives.  Since the SIGALRM is programmatically
generated, I'm hopeful it isn't a documented admin knob on the program,
and therefore changing the signal number won't be a problem...

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert@fledge.watson.org      Network Associates Laboratories