>> 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*!  ;-)

It may not be a bug, but it definitely is a problem.

> A non-privileged process should not be able to give up all traces of
> its origins,

Which is fine.  The problem is that all the places such trace could be
kept also grant privilege, namely, the privilege to run as that uid.
What you need is to split the suid into an original-suid, which cannot
be changed but grants no power regardless of how it's set, and an
effective-suid, which grants power but can be reset.

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

It would, for example, make it impossible for a setuid-games executable
to, say, open a high-score file and then permanently give up all
suidness (thereby making it impossible to regain uid games even through
things like stack-scribbling bugs).

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

But - at least from what I've seen reported here - the POSIX security
model is broken, in that it _requires_ overloading the suid as both a
uid whose access rights are available and as an un-relinquishable
indicator of origin.  To put it more briefly, the POSIX model, as it
stands now, deliberately makes it impossible to do "least privilege"
setuid programs - the program either has to be setuid root, which is
more privilege than it needs in many cases, or it cannot give up its
power, thus leaving it wide open to any stack-smash bug.

Get POSIX to require - or at least allow - the saved-set-id to be split
into a saved-set-id that one can seteuid() to but that one can also
copy the ruid into at will, and a saved-set-id that one cannot change
but that grants no power, and _then_ I'd have no quarrel with NetBSD
adopting it.

To answer your question: in many cases, the security policy is _not_
"the most important feature of all" of POSIX compliance.  Lots of
people just want their code to build and don't give a damn about
whether the system matches the POSIX security model as long as whatever
it is is relatively secure.  Programs that actually depend on the POSIX
security model are relatively rare, I suspect, and tend to be system
fragments anyway (eg, login, su) that need to know exactly what the
system's model is, not just whether it happens to be POSIX-compatible.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu