> > On the other hand, for example, rshd already checks a
> > ~/.rhosts file permission in lib/libc/net/rcmd.c.  It just
> > changes effective uid while opening .rhosts file.  This
> > implemetaion seems enough simple.  Does following code have
> > a problem?  Probably it has since I've just written this.
> > But is this idea wrong?
> 
> Since hostalias() is in the library code and it is not called
> explicitly, hostalias() cannot know what uid/gid should be used
> to check permission.  Suppose the application may call gethostbyname()
> even after it swaps ruid and euid.

I've talked this issue with Charles privately, but haven't have
time to post summary publically. (sorry)

The source of this problem is setreuid(2).
If setreuid(2) is never used from userland, the following pseudo code
should work.

	uid_t saved_euid, real_uid;
	gid_t saved_egid, real_gid;

	if (((saved_euid = geteuid()) != (real_uid = getuid()) ||
	     (saved_egid = getegid()) != (real_gid = getgid()))) {

		/* back to real uid/gid privilege */
		if (saved_euid != real_uid) {
			if (seteuid(real_uid) == -1)
				error;
		}
		if (saved_egid != real_gid) {
			if (setegid(real_gid) == -1)
				error;
		}

		fp = fopen($HOSTALIASES, "r");

		/* re-acquire effective uid/gid privilege */
		if (saved_euid != real_uid) {
			if (seteuid(saved_euid) == -1)
				error;
		}
		if (saved_egid != real_gid) {
			if (setegid(saved_egid) == -1)
				error;
		}
	} else {
		fp = fopen($HOSTALIASES, "r");
	}

Please note that since we have saved uid feature, there is no reason
to use setreuid(2) any more.
So, the very brief conclusion of the private talk is that we should
remove setreuid(2) from our userland. (and recover the $HOSTALIASES
feature.)

And as far as I know, Charles sweeped all setreuid(2) from NetBSD
userland at that time.

We have to sweep setreuid(2) from pkgsrc and xsrc too, though.
This sweeping job is relatively hard, but since the programs which
should be fixed are all setuid/setgid programs, the job should not
be too hard.

Please note 3rd party software should not use setreuid(2) anyway.
Since the issetgid(2) way is not portable to other UNIXes, if the
software uses setreuid(2), the software must have security hole on
other systems.
--
soda