From owner-cvs-all@FreeBSD.ORG Sun Sep 14 12:21:56 2003 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 446A216A4BF; Sun, 14 Sep 2003 12:21:56 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2275F43FCB; Sun, 14 Sep 2003 12:21:54 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id FAA17440; Mon, 15 Sep 2003 05:21:49 +1000 Date: Mon, 15 Sep 2003 05:21:48 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Robert Watson In-Reply-To: Message-ID: <20030915045026.D2197@gamplex.bde.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE cc: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org cc: cvs-src@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2003 19:21:56 -0000 On Sun, 14 Sep 2003, Robert Watson wrote: > On Sun, 14 Sep 2003, Dag-Erling Sm=F8rgrav wrote: > > > Robert Watson writes: > > > That said, to be frank, no, I'm not sure I want to do this. But I al= so > > > want to make sure we don't break important applications. > > > > What about important applications that rely on the fact that > > unprivileged users can't send SIGALRM to privileged processes? That > > used to be the case for ping(8) (though I don't think it is any more), > > and there may be others. Shouldn't we err on the side of caution? > > Well, until 5.x, this limit didn't exist, so right now I think this is > still a question of "how conservative to we want to be relative to the > status quo". I agree in principle, but we should get the Diablo port > (software?) fixed first. Important applications can't rely on this, by the definition of important :-). The behaviour is implementation defined, so portable applications can't rely on any particular behaviour except possibly if they read and understand the system documentation at appropriate times (perhaps on receipt of the signal in the worst case). The FreeBSD behaviour changed recently, so important applications must handle the old behaviour. The old behaviour is normal, so important applications must handle it. The particular case of SIGALRM is fairly easy to handle, and ping(8) handles it. Most SIGALRMs result in premature termination of a syscall, with errno EINTR, and the correct handling of this is normally to do nothing in the SIGARLM handler check the time on EINTR-return from the syscall to see if the SIGALRM is (or could be) a programmed one. ping(8) does this, except possibly when it is in libc. Unfortunately, ping6(8) diverged from the FreeBSD ping(6) before this was fixed, and still seems to be missing many of the improvements in the FreeBSD ping(6), including this. POSIX.1-200x-draft7 on permissions for kill(2): %%% 22150 For a process to have permission to send a signal to a p= rocess designated by pid, unless the 22151 sending process has appropriate privileges, the real or = effective user ID of the sending process 22152 shall match the real or saved set-user-ID of the receivi= ng process. %%% This clause specifies the "normal" behaviour (no restrictions related to setuidness). %%% 22168 An implementation that provides extended security contro= ls may impose further 22169 implementation-defined restrictions on the sending of si= gnals, including the null signal. In 22170 particular, the system may deny the existence of some or= all of the processes specified by pid. %%% This clause permits any behaviour provided the behaviour is documented. FreeBSD uses this clause to increase security, but breaks POSIX confomance by not documenting the behaviour. Bruce