[ On Wednesday, November 22, 2000 at 18:36:07 (-0800), Greywolf wrote: ]
> Subject: Re: Addition to force open to open only regular files
>
> Sarcastic?  Yes.  Facetious?  Of course.  But we're rewriting some major
> semantics which I'm not entirely convinced need to be rewritten.

I don't know what you're talking about here for sure, but what I've been
talking about is only just the return to the original, once patented,
tried and true, setuid() semantics, and then to only re-extend them
again to the very bare minimum necessary to work around flaws and
omissions in the original APIs.

The first attempt at working around these fundamental flaws and
omissions, setreuid() and setregid(), was a poorly thought out, poorly
implemented idea that attempted to solve a problem but could only just
barely succeed with the utmost care to attention and detail.  The
resulting API was complex to use and was unable to provide good error
reporting.

The next attempt with seteuid() and setegid() was a refinement of that
original idea that made it much easier for a set-ID programmer to solve
some of the problems inherent in the plain old setuid() interface.

Unfortunately the fundamental concept of saved-set-ID swapping employed
by both of these "extensions" has turned out to have at least two major
flaws of its own -- flaws that in combination are significant enough
that many of us who've written or maintained set-ID programs have chosen
to avoid all of these new interfaces completely.  (These flaws are far
from being quite as critical as the major flaw this feature is designed
to work around, mind you.)

The existance of one of these flaws has also resulted in the split
between how the API for seteuid() works in the two different major
families of Unix and Unix-like systems where it does exist, further
complicating and clouding the issue for authors and maintainers of
portable set-ID programs who do choose to use it in their
implementations.

Furthermore it seems that there's some strong desire to keep various
features, even within set-ID programs, which involve standard and
commonly used library routines accessing files specified by the user in
environment variables.  However even the current saved-set-ID swapping
feature, which technically could provide a solution, is somewhat
difficult to use safely and cleanly from within the black box of a
library call implementation, at least with currently available APIs.

All of this together means it's necessary to find some compromise --
something part way in between having to always to do every file access
with a separate process, vs. being able to flip back and forth between a
privileged and unprivileged state with no bounds or controls.

However fundamentally there's no major paradigm shift necessary, and
except for programs which have completely misused either of the new APIs
due to misconceptions and false pretenses, the conversion of the few
existing programs which would need changes to use a new API like
open_as() is relatively straight forward and sometimes even quite simple
to do.

So to borrow a phrase from a famous USA radio broadcaster, now you know
the rest of the story....

-- 
							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>