From owner-freebsd-security  Mon Aug  4 10:37:35 1997
Return-Path: <owner-freebsd-security>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id KAA14664
          for security-outgoing; Mon, 4 Aug 1997 10:37:35 -0700 (PDT)
Received: from enteract.com (enteract.com [206.54.252.1])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA14647
          for <security@FreeBSD.ORG>; Mon, 4 Aug 1997 10:37:30 -0700 (PDT)
Received: (from tqbf@localhost) by enteract.com (8.8.5/8.7.6) id MAA01264; Mon, 4 Aug 1997 12:22:09 -0500 (CDT)
From: "Thomas H. Ptacek"  <tqbf@enteract.com>
Message-Id: <199708041722.MAA01264@enteract.com>
Subject: Re: Proposed alternate patch for the rfork vulnerability
To: bde@zeta.org.au (Bruce Evans)
Date: Mon, 4 Aug 1997 12:22:07 -0500 (CDT)
Cc: bde@zeta.org.au, tqbf@enteract.com, security@FreeBSD.ORG, sef@Kithrup.COM
Reply-To: tqbf@enteract.com
In-Reply-To: <199708041658.CAA02664@godzilla.zeta.org.au> from "Bruce Evans" at Aug 5, 97 02:58:51 am
X-Mailer: ELM [version 2.4 PL24 ME8a]
Content-Type: text
Sender: owner-freebsd-security@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> >> I think exec should just fail if it can't honour setuid'ness.  For ptrace
> >Why? What does this win?
> Conformance with the rfork man page:

> It doesn't say that exec turns off the sharing.

exeve() doesn't "turn off the sharing". Execution of an SUID program in a
process that shares a file descriptor table causes the SUID bit not to be
honored; this is a semantic with precedent (NOSUID, ptrace).

----------------
Thomas Ptacek at EnterAct, L.L.C., Chicago, IL [tqbf@enteract.com]
----------------
"If you're so special, why aren't you dead?"