> > Half-open, open-only-normal-files, fsetuid, open_as are all insufficient,
> > because there are system calls other than open(2) which is related to
> > user's privilege.
> > The saved-uid/gid feature can do what those can do, and can cope with
> > system calls other than open(2), too.
> 
> Exactly.  And that's the problem, not the solution.
> 
> Of all the proposals so far open_as() is the only one that provides
> sufficient functionality to solve the entire class of problems while at
> the same time not making a new set of problems for itself.

I cannot understand the above statement.
If I understand correctly,

	fd = open_as(filename, ...., real_uid);

is just same with the following code:

	if ((euid = geteuid()) == real_uid) {
		fd = open(filename, ...);
	} else {
		seteuid(real_uid);
		fd = open(filename, ...);
		seteuid(euid);
	}

So, saved-uid/gid feature can do what open_as() can do.
And, open_as() cannot do what saved-uid/gid can do.

We already have saved-uid/gid feature, we currently don't have
open_as().

Saved-uid/gid is almost portable on all POSIX based systems(*),
open_as() is not portable at all.

So why you'd say "open_as is the only one that provides sufficient
functionality"?

I seemd to recall that calling open_as() can automatically disable
setreuid(2)/setregid(2). But that doens't solve any problem.
The setreuid(2)/setregid(2) problem is that a application can
call setreuid(2)/setregid(2) before calling a library function
which calls open(2), so, the library function cannot know
how to drop it's setuid privilege. Open_as() doesn't solve this
problem. So, there is nothing that open_as() is better than
saved-uid/gid feature.

(*) The reason that our saved-uid/gid feature is not compatible
  with POSIX_SAVED_ID is:
	In POSIX_SAVED_ID, only root-setuid program can drop
	it's saved uid by setuid(2), normal-user-setuid program
	cannot drop it's saved uid.
	In NetBSD, normal-user-setuid program can drop it's
	saved uid privilege.
--
soda