Date: Mon, 15 Sep 2003 05:21:48 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Robert Watson <rwatson@FreeBSD.org> Cc: cvs-src@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_prot.c Message-ID: <20030915045026.D2197@gamplex.bde.org> In-Reply-To: <Pine.NEB.3.96L.1030914130145.19668A-100000@fledge.watson.org> References: <Pine.NEB.3.96L.1030914130145.19668A-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 14 Sep 2003, Robert Watson wrote: > On Sun, 14 Sep 2003, Dag-Erling Sm=F8rgrav wrote: > > > Robert Watson <rwatson@FreeBSD.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030915045026.D2197>