Date: Sun, 14 Sep 2003 11:43:32 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= <des@des.no> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_prot.c Message-ID: <Pine.NEB.3.96L.1030914113941.19069B-100000@fledge.watson.org> In-Reply-To: <xzpu17fppjq.fsf@dwp.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1030914113941.19069B-100000>