Subject: Re: Addition to force open to open only regular files
To: None <>
From: Noriyuki Soda <>
List: tech-kern
Date: 11/23/2000 04:07:07
soda> Why do you ignore the following option?
soda> 	Deprecate setreuid(2) and setregid(2).
soda> 	Use saved-uid/gid feature to drop privilege.

> There are two reasons.  First, we have no knowledge of the saved uid
> in userland.  There's no way to know what it is.

This is not problem at all, if we never use setreuid(2)/setregid(2).
Because library function don't have to know the saved uid anyway,

To drop privilege:
	a library function have to know the value of getuid(),
	not the saved uid.
To recover original privilege:
	a library function have to know the value of geteuid(),
	not the saved uid.
as shown in the following your example:
> 	if ((oldeuid = geteuid()) != getuid())
> 		seteuid(getuid());
> 	do it
> 	if (oldeuid != getuid())
> 		seteuid(oldeuid);

> For most people and most applications, this would be sufficient.  If
> we depricated the full functionality of setreuid, then it would be
> sufficient for most cases.

We don't have to remove the functionality of setreuid(2)/setregid(2).
What we should do is to declare that setreuid(2)/setregid(2) shouldn't
be used just like gets(3) shouldn't be used.

(NetBSD cannot remove the functionality of setreuid(2)/setregid(2),
 because the major number of libc will almost never change...)

> Even if we didn't, it would then be up to the setreuid using program
> to scrub their environment when necessary.  A simple library call
> would make this portable and useful.
> In the case where a setuid root program did something like:
> 	setreuid(12, 45)
> for whatever reason (which is the example of why we can't just do the
> above), then we'd require that it also add a call like:
> 	sanitize_environment();
> 	setreuid(12, 45);
> which would solve nearly all, if not all, of these problems.

I think we don't have to implement the sanitize_environment(),
as you said the following sentence:

> the number of programs that do this is vanishingly small (eg, I've
> never actually seen one that set uids so arbitrarily)

> Maybe it is time to put a warning into code that does this ala the
> gets warning.

I agree with this.