std-unix@ut-sally.UUCP (Moderator, John Quarterman) (02/06/86)
Date: Wed, 5 Feb 86 08:12:33 pst
>From: seismo!sun!rtech!daveb (Dave Brower)
Organization: Relational Technology Inc, Alameda CA
At first glance I thought clearing the environment on the exec of a setuid
program might be OK, but it seems full of awkward side effects.
For instance, I could not have one of my favorite programs, nasty, that
runs setuid root and then execs the remainder of its arguments with
a negative nice value. The real child process would never be able to
get a reasonable environment.
The answer is only to do limited operations when in setuid. The best
way to do this would be to allow processes to painlessly shift back and
forth between their real-uid and effective-uid. This is allowed, but
not documented on BSD, but appears not to be allowed at all on SV.
This way, you can have your one section that need to run setuid be setuid
whenver needed, while running as the real user the reset of the time.
Lastly, you really need to be able to set fixed priorities rather than
just nice values so things like a memory/cpu pig server process can avoid
getting bumped. Convex did this by making nice values < -20 and > +20
be a fixed priority. This seems quite reasonable, and lets a 'nasty'
root program set the fixed high priority.
-dB
Volume-Number: Volume 5, Number 39std-unix@ut-sally.UUCP (Moderator, John Quarterman) (02/08/86)
>From: seismo!gatech!akgua!pegasus!hansen (Tony Hansen)
Sat Feb 8 00:48:16 1986
Date: Sat, 8 Feb 86 00:31:29 EST
Organization: AT&T-IS Labs, Lincroft, NJ
< The answer is only to do limited operations when in setuid. The best
< way to do this would be to allow processes to painlessly shift back and
< forth between their real-uid and effective-uid. This is allowed, but
< not documented on BSD, but appears not to be allowed at all on SV.
System Vr2 allows a non-root setuid process to call setuid(2) with either
the real uid or the saved effective uid, allowing the process to painlessly
switch back and forth. This change occurred between System V and Vr2.
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.
Tony Hansen
ihnp4!pegasus!hansen
Volume-Number: Volume 5, Number 43std-unix@ut-sally.UUCP (Moderator, John Quarterman) (02/11/86)
>From: Kay Dekker <seismo!mcvax!warwick!kay> To: ut-sally!std-unix Organization: Computer Science, Warwick University, UK Date: Sat, 8 Feb 86 10:20:38 GMT >Date: Wed, 5 Feb 86 08:12:33 pst >>From: seismo!sun!rtech!daveb (Dave Brower) >Organization: Relational Technology Inc, Alameda CA > >The answer is only to do limited operations when in setuid. The best >way to do this would be to allow processes to painlessly shift back and >forth between their real-uid and effective-uid. This is allowed, but >not documented on BSD, but appears not to be allowed at all on SV. >This way, you can have your one section that need to run setuid be setuid >whenver needed, while running as the real user the reset of the time. This is *exactly* what I found myself needing to do last night... When you say "BSD", does this include 4.1? If so, how do I do it? and why isn't it documented? Kay. -- Virtue is its own punishment. ... mcvax!ukc!warwick!kay [ It was introduced in 4.2BSD. Here's the man page. Note that only super-user can actually switch back and forth between ruid and euid. -mod ] SETREUID(2) UNIX Programmer's Manual SETREUID(2) NAME setreuid - set real and effective user ID's SYNOPSIS setreuid(ruid, euid) int ruid, euid; DESCRIPTION The real and effective user ID's of the current process are set according to the arguments. If _r_u_i_d or _e_u_i_d is -1, the current uid is filled in by the system. Only the super-user may modify the real uid of a process. Users other than the super-user may change the effective uid of a process only to the real uid. RETURN VALUE Upon successful completion, a value of 0 is returned. Oth- erwise, a value of -1 is returned and _e_r_r_n_o is set to indi- cate the error. ERRORS [EPERM] The current process is not the super-user and a change other than changing the effective user-id to the real user-id was specified. SEE ALSO getuid(2), setregid(2), setuid(3) Printed 2/11/86 12 February 1983 1 Volume-Number: Volume 5, Number 44
std-unix@ut-sally.UUCP (Moderator, John Quarterman) (02/11/86)
Date: Sun, 9 Feb 86 22:00:20 pst >From: pyramid!csg (Carl S. Gutekunst) Organization: Pyramid Technology Corp., Mountain View, CA >> The answer is only to do limited operations when in setuid. The best >> way to do this would be to allow processes to painlessly shift back and >> forth between their real-uid and effective-uid. This is allowed, but >> not documented on BSD, but appears not to be allowed at all on SV. > >System Vr2 allows a non-root setuid process to call setuid(2) with either >the real uid or the saved effective uid, allowing the process to painlessly >switch back and forth. This change occurred between System V and Vr2. Something is silly here; if you think it's important I'd appreciate it if you'd verify this with someone who knows: System V has always had the ability to switch the effective UID between the real UID and the saved effective UID. (And it isn't documented, BTW. We discovered it the hard way when some of the V.0 utilities wouldn't run.) Berkeley, however, has never had this capability. There are a number of other curious variations and exceptions, although that's fodder for net.unix... :-) [ Does anybody know when the capability was introduced? PWB, System III, System V? As for what BSD has along these lines, see previous article. I'm beginning to agree that this discussion really belongs on net.unix. -mod ] <csg> Volume-Number: Volume 5, Number 45
std-unix@ut-sally.UUCP (Moderator, John Quarterman) (02/11/86)
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