>  |    Modified Files:
>  |    	basesrc/lib/libc/net: res_query.c
>  |    
>  |    Log Message:
>  |    don't look at $HOSTALIASES, if issetugid() says the binary is dirty.
>  | 
>  | i really hate this change.
>Same here.   What's the problem supposed to be, aside from FUD ?
>As long as the library routines that read $HOSTALIASES are doing it
>properly (if it wants to be super safe, abandon stdio and just malloc
>a buffer, or use the stack, read(2) into it, then zap the buffer (memset())
>before returning to user code).   But setuid() binaries that allow users
>to get access to data in their mem leave more holes than can be exploited
>via HOSTALIASES.

	there are more issues than coredump scenario (stdio buffer visible)
	jason mentioned - actually, by allowing $HOSTALIASES couple of other
	attack scenarios are possible.  basically, we can never allow fopen()
	in setuid'ed privilege here.

	there are couple of ways to fix it:
	- disallow $HOSTALIASES for setuid'ed binary - the committed one
	- open $HOSTALIASES in real uid, in library code only - very hard
	  to achieve, many presented me diffs to do this but aren't very correct
	- open $HOSTALIASES in real uid, using some help from new
	  openwithrealuid()-like system call - not sure if we want it now
	- assume all users of DNS resolver function to drop setuid
	  before calling any name resolution functions - NO WAY

	The first solution has been in FreeBSD and OpenBSD for more than
	3 years.

>So, is this change any more than a reaction to a bug that was in SunOS?

	are you talking about coredump case?  no.

>And if not, can it be undone please?

	the situation is much worse.

itojun