> the problem with _POSIX_SAVED_IDS is that it does *not*
   > allow a setuid non-root program to entirely give up the
   > setuid ness.
   
   That's not a problem -- that's a *feature*!  ;-)

in what way ?
   
   A non-privileged process should not be able to give up all traces of its
   origins, and thus should not be able to re-set p_ruid and especially not

why is this ?

   p_svuid.  (4bsd setreuid() changes p_ruid, but only because it didn't
   already have p_svuid for the same purpose -- new implementations could
   probably give up this, if implemented very carefully, for sake of the
   new policy as I can't imagine anything that might depend upon it)
   
   I'd sure like to understand what people think they'd lose if setuid() et
   al were made POSIX compliant.  Does anyone have any practical examples?

/usr/games is one.

if i have a program that i want to have "some" privileges
(ie, it can read a file owned by user `foo'), i make it
set-uid (to user foo). if, after i've read this file, i
decide, being a security conscience coder, that i no longer
need the ability to read this file (ie, it may be a start up
file, say a license), i want to revoke these priviledges.

yes, i can use 'exec' to get around this but this is an evil
hack.

   
   > i can remember noticing this not defined some time ago
   > (1994ish) and reading up about this in steven's book. i
   > remember disagreeing with what steven's said, at the time.
   
   Stevens doesn't say anything disagreeable -- he's just reporting the
   facts.  If you wish to disagree, take issue with Research UNIX, and
   subsequently the AT&T SVID and/or the DoD (and/or the Canadian DND, or
   the French, etc.).

i can't really remember what it was -- it was some time ago.
the point being that i didn't like what was being said :)
   
   > i really like our current saved userid model. the only
   > reason charles is proposing to add setre[gu]id() back is for
   > compatibility -- the current interfaces aren't correct and
   > can cause problems (perl is one that loses because of this).
   
   What's the point of trying to achieve POSIX compliance if the most
   important feature of all (i.e. security policy) is not also compliant
   (or at bare minimum compile-time configurably compliant)????

reading http://www.netbsd.org/, i find:

NETBSD STANDARDS CONFORMANCE
 
NetBSD tries to conform to important industry standards
like *POSIX* and *Standard C*. No efforts have been made to
conform to [[X/Open]] *Spec 1170*, since we believe that
codifying the superset of all API's all the way back to
Version 7 is not the right way to make a standard.

POSIX (Portable Operating Systems Interface) is the name
used by group of standards sponsored by the [[IEEE]] that
define a standard API for UNIX-like operating systems.
POSIX.1 (IEEE Std1003.1-1990) standardizes the API for C.
POSIX.2 (IEEE Std1003.2-1992) standardizes the Shell and
Utilities. Other POSIX standards cover Ada and Fortran
bindings, real time extensions, conformance testing, etc.

NetBSD is extremely close to being POSIX.1 compliant. There
are a few nits we know about: some we plan to fix, and
others we plan to ignore until a future revision of POSIX.1
``fixes'' them for us.


the last bit is especially relevant, as, this setuid discussion
is part of what the above is saying.

in what way is not defining _POSIX_SAVID_IDS not conformant?

.mrg.