From owner-freebsd-security  Fri Apr 21 07:37:19 1995
Return-Path: security-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id HAA08528
          for security-outgoing; Fri, 21 Apr 1995 07:37:19 -0700
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34])
          by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id HAA08505
          for <freebsd-security@FreeBSD.org>; Fri, 21 Apr 1995 07:36:46 -0700
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id AAA23449; Sat, 22 Apr 1995 00:31:34 +1000
Date: Sat, 22 Apr 1995 00:31:34 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199504211431.AAA23449@godzilla.zeta.org.au>
To: erandall@muffit.reo.dec.com, freebsd-security@FreeBSD.org
Subject: Re: Call for remove setr[ug]id() and setre[ug]id() from libc
Sender: security-owner@FreeBSD.org
Precedence: bulk

>Exactly which functions are you planning to remove :
>and from where ?

setruid		remove (library)
setreuid	remove (library)
setrgid		remove (library)
setregid	remove (library)
osetreuid	? (syscall)
osetregid	? (syscall)
seteuid		keep? (syscall)
setegid		keep? (syscall)

>Please be aware that if you simply remove something, you will most likely
>prevent various (unknown) applications from compiling.

This is really the point.  If the applications expect 4.3BSD semantics
then they may not work right with 4.4BSD semantics.  They need to be
checked for new security holes, and the compatibility functions can
easily be replaced as part of the checking.

>Wouldn't it be better to FIX these functions to match the POSIX standard, and 
>patch up the security holes ?  POSIX compliance has surely to be the goal, and
>removing any POSIX functions altogether will miss the target as surely as if
>the functions are broken.

All of these functions are outside the POSIX standard.

Bruce