From owner-freebsd-security  Mon Aug  4 13:37:47 1997
Return-Path: <owner-freebsd-security>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id NAA25571
          for security-outgoing; Mon, 4 Aug 1997 13:37:47 -0700 (PDT)
Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA25551
          for <security@FreeBSD.ORG>; Mon, 4 Aug 1997 13:37:42 -0700 (PDT)
Received: from znep.com (uucp@localhost)
	by scanner.worldgate.com (8.8.5/8.8.5) with UUCP id OAA16885
	for security@FreeBSD.ORG; Mon, 4 Aug 1997 14:37:41 -0600 (MDT)
Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id OAA28914 for <security@FreeBSD.ORG>; Mon, 4 Aug 1997 14:36:54 -0600 (MDT)
Date: Mon, 4 Aug 1997 14:36:54 -0600 (MDT)
From: Marc Slemko <marcs@znep.com>
To: security@FreeBSD.ORG
Subject: Re: Proposed alternate patch for the rfork vulnerability
In-Reply-To: <19970804195706.9133.qmail@ishiboo.com>
Message-ID: <Pine.BSF.3.95.970804143554.27439R-100000@alive.znep.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-security@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

On Mon, 4 Aug 1997 nirva@ishiboo.com wrote:

> Sean Eric Fagan stands accused of saying:
> > I'm sorry, Bruce, but having the file descriptor sharing break on
> > exec is the ONLY way to have it make sense, let alone be secure.
> > 
> 
> Breaking file descriptor sharing is breaking the established sematics
> of rfork().

I'm not sure I like breaking sharing on execs either.

An alternative I haven't seen mentioned is simply haveing exec() fail if
it tries to exec a setuid program when descriptors are being shared.  If
someone isn't checking the return from exec, that is their problem.