From owner-freebsd-bugs  Mon Oct 13 12:20:09 1997
Return-Path: <owner-freebsd-bugs>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id MAA16690
          for bugs-outgoing; Mon, 13 Oct 1997 12:20:09 -0700 (PDT)
          (envelope-from owner-freebsd-bugs)
Received: (from gnats@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id MAA16648;
          Mon, 13 Oct 1997 12:20:02 -0700 (PDT)
          (envelope-from gnats)
Date: Mon, 13 Oct 1997 12:20:02 -0700 (PDT)
Message-Id: <199710131920.MAA16648@hub.freebsd.org>
To: freebsd-bugs
Cc: 
From: Nate Williams <nate@mt.sri.com>
Subject: Re: kern/4755: coredump refusal of setuid programs too restrictive
Reply-To: Nate Williams <nate@mt.sri.com>
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

The following reply was made to PR kern/4755; it has been noted by GNATS.

From: Nate Williams <nate@mt.sri.com>
To: pst@shockwave.com
Cc: FreeBSD-gnats-submit@freebsd.org, security-officer@freebsd.org,
        bde@freebsd.org, phk@freebsd.org
Subject: Re: kern/4755: coredump refusal of setuid programs too restrictive
Date: Mon, 13 Oct 1997 13:09:41 -0600 (MDT)

 Paul Traina writes:
 > 
 > >Number:         4755
 > >Category:       kern
 > >Synopsis:       we should allow coredumps of setuid code if uid==0
 > >Confidential:   no
 > >Severity:       non-critical
 > >Priority:       high
 > >Responsible:    freebsd-bugs
 > >State:          open
 > >Class:          sw-bug
 > >Submitter-Id:   current-users
 > >Arrival-Date:   Mon Oct 13 10:10:01 PDT 1997
 > >Last-Modified:
 > >Originator:     Paul Traina
 > >Organization:
 > Juniper Networks
 > >Release:        FreeBSD 3.0-CURRENT i386
 > >Environment:
 > 
 > This is relevant in 2.2.x and 3.0.
 > 
 > >Description:
 > 
 > Currently, if a program is setuid, we don't take a core, period.
 > This makes it very difficult to debug certain types of problems.
 > 
 > >How-To-Repeat:
 > 
 > Dump core in a setuid program invoked by root.
 > 
 > >Fix:
 > 	
 > The code should be changed to check the uid (maybe saved uid?) of
 > the current invoker and remove the restriction if that uid is 0.
 
 I think the only safe fix to have use a sysctl that enables it.  There
 are too many things that would still 'unsafely' dump core with any kind
 of check you can come up with.  By allowing it to be disabled easily by
 a root user, you allow a developer/user to allow core dumps, with the
 knowledge that the system is no longer secure.
 
 
 Nate