From owner-freebsd-security  Wed Feb 19 09:38:32 1997
Return-Path: <owner-security>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id JAA05697
          for security-outgoing; Wed, 19 Feb 1997 09:38:32 -0800 (PST)
Received: from saguaro.flyingfox.com (saguaro.flyingfox.com [204.188.109.253])
          by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA05692
          for <security@freebsd.org>; Wed, 19 Feb 1997 09:38:30 -0800 (PST)
Received: (from jas@localhost) by saguaro.flyingfox.com (8.6.12/8.6.10) id JAA16579; Wed, 19 Feb 1997 09:32:00 -0800
Date: Wed, 19 Feb 1997 09:32:00 -0800
From: Jim Shankland <jas@flyingfox.COM>
Message-Id: <199702191732.JAA16579@saguaro.flyingfox.com>
To: caseq@magrathea.chance.ru, dg@root.com, jas@flyingfox.COM,
        rbezuide@oskar.nanoteq.co.za, security@freebsd.org
Subject: Re: Coredumps and setuids .. interesting..
Sender: owner-security@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

David Greenman writes:

> A correction...the signal sender need only match *either* the real or
> effective uid of the signal receiver....
> 
> I actually didn't know it was this open until I read the manual page. I
> believe this behavior is required by POSIX, so it's not likely something
> that we would want to change.

It's not only a standard, it's even useful.  Think of a non-privileged
client process that runs a setuid-somebody (not necessarily root)
server process for, say, database access.  The server process,
being privileged, has unfettered access to the database, but
permission-checks accesses requested of it by the client.  The
client may still want to signal the server process to abort a long-running
query, for example.

Jim Shankland
Flying Fox Computer Systems, Inc.