Subject: re: Addition to force open to open only regular files
To: NetBSD Kernel Technical Discussion List <tech-kern@netbsd.org>
From: Greg A. Woods <woods@weird.com>
List: tech-kern
Date: 11/16/2000 16:50:36
[ On Thursday, November 16, 2000 at 00:20:04 (-0800), Greywolf wrote: ]
> Subject: re: Addition to force open to open only regular files 
>
> But a process can, as super-user, fork(), setuid(non-superuser), do its
> thing and return as it is, and it can communicate state back and forth
> with its parent if so written, to the extent that it is performing the
> exact same function as though it were allowed to revert to setuid(superuser).

Exactly right.

> The only thing that POSIX does is make it more inconvenient to do this,
> and this is not always a good thing.  If the program is certain it's
> not going to need to return to being super-user, it should be written
> as such at that point.

No, not really.  POSIX makes it necessary to do this.  In BSD you can
just use sete*id() and swap back and forth without having to fork() and
once you're sure you don't need your saved-set-IDs any more you can just
blow them away with a setuid(getuid()); /* drop to real user permanently */

(I'm not 100% sure this has always been true on all versions of all unix
and unix-like systems that have tried to implement saved-set-ID though.)

> This is yet another thing that bothered me about SVID/POSIX/SUS2 in
> the first place.  I thought Berkeley, though stepping out on a limb,
> did The Right Thing.

Any saved-set-ID swapping is stepping out on a rather shaky and already
broken and bent and partly braced up limb.

A portable set-ID-root program must not use sete*id() if it is to avoid
making its implementation on some platforms vulnerable to compromise and
if it is to avoid trapping itself as the real user and not being able to
swap back to its saved-set-ID privs.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>