cvs commit: src/sys/kern kern_prot.c

[Bruce Evans]

On Sun, 14 Sep 2003, Robert Watson wrote:

> On Sun, 14 Sep 2003, Dag-Erling Sm=F8rgrav wrote:
>
> > Robert Watson <rwatson at 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