Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 5 Jul 2011 09:46:52 +0100 (BST)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        exorcistkiller <exorcistkiller@gmail.com>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: priv_check() question
Message-ID:  <alpine.BSF.2.00.1107050937310.81242@fledge.watson.org>
In-Reply-To: <1309762465080-4549149.post@n5.nabble.com>
References:  <1309762465080-4549149.post@n5.nabble.com>

next in thread | previous in thread | raw e-mail | index | archive | help

On Sun, 3 Jul 2011, exorcistkiller wrote:

> Hi! I am taking a FreeBSD course this summer and I'm doing a homework. A new 
> system call uidkill() is to be added. uidkill(uid_t uid, int signum) sends 
> signal specified by signum to all processes owned by uid, excluding the 
> calling process itself.
>
> I'm almost done, however I get stuck with priv_check(). If the calling 
> process is trying to send signal to processes owned by others, permission 
> should be denied. My implementation simply uses an if (p->p_ucred->cr_uid == 
> ksi.ksi_uid) to deny it, however priv_check() is required. My question is: 
> what privilege a process should have to send signal to processes owned by 
> others? PRIV_SIGNAL_DIFFCRED?

The right way to think about "privileges" in FreeBSD is that they exempt 
subjects (usually processes) from normal access control rules -- typically as 
a result of a root uid.  The access control rules for signalling are captured 
by p_cansignal() and cr_cansignal(), depending on whether the "subject" is a 
process or a cached credential.  Processes have access to slightly greater 
rights than raw credentials due to additional context -- for example, 
information about parent-child relationships.  These functions then invoke 
further privilege checks if required, perhaps overriding the normal 
requirement that uids match, etc.  kill() implements a couple of broadcast 
modes for signals -- you may want to look at the implementation there to see 
how this is done.

Robert




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1107050937310.81242>