Subject: Re: Addition to force open to open only regular files
To: None <imp@village.org>
From: Noriyuki Soda <soda@sra.co.jp>
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.
--
soda