Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ut-sally.UUCP
Path: utzoo!decvax!decwrl!pyramid!ut-sally!std-unix
From: std-unix@ut-sally.UUCP (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re:  Clearing environment on exec of setuid process
Message-ID: <4164@ut-sally.UUCP>
Date: Tue, 11-Feb-86 11:20:24 EST
Article-I.D.: ut-sally.4164
Posted: Tue Feb 11 11:20:24 1986
Date-Received: Wed, 12-Feb-86 02:36:43 EST
References: <4128@ut-sally.UUCP> <4106@ut-sally.UUCP> <4029@ut-sally.UUCP> <4141@ut-sally.UUCP>
Reply-To: thomas@utah-gr.UUCP (Spencer W. Thomas)
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 24
Approved: jsq@sally.UUCP

Date: Mon, 10 Feb 86 11:06:44 MST
>From: thomas%utah-gr@UTAH-CS.ARPA (Spencer W. Thomas)
Organization: University of Utah, Salt Lake City

In article <4141@ut-sally.UUCP> pegasus!hansen (Tony Hansen) writes:
>One slight difference is that Vr2 non-root setuid(2) sets the effective uid
>and not the real uid. Only a root setuid(2) will change the real uid as
>well; which can't then be changed back.

This seems to me to be a potential security problem.  It means that you
cannot write a program to give a certain set of people access to a
particular uid (ala su) without making it setuid root.  It would be much
safer, it seems to me, to make it setuid to the uid you want to give
access to, and let it do setuid(geteuid()).  This is necessary if, for
example, the program wants to fork a real setuid program with the new
uid.  We have a number of programs that do this.  Yet another reason to
not use SV.

[ Please, let's not start up the System V vs. 4BSD argument here.  -mod ]

-- 
=Spencer   ({ihnp4,decvax}!utah-cs!thomas, thomas@utah-cs.ARPA)

Volume-Number: Volume 5, Number 46