Re: libresolv+ bug

[casper () holland Sun COM (Casper Dik)]

> On Sun, 18 Aug 1996, Nelson Murilo wrote:
>
> > Hi my solution is very hard, i'm deleted getenv() options from
> > gethsnmad.c in libc-5.3.12 for Linux.
> > Possible not elegant, but funcionality :)
>
> The better solution is probably to do things such as ld.so does, and only
> remove the variables if it is a suid or sgid program, although removing
> support for them totally works too :).


Unfortunately, there's a big difference between when ld.so gets called
first and when your routine gets called first. ld.so can have a notion of
whether a program was set-uid, as it is called at program start.
Library functions, on the other hand, are called possibly after a program
may have altered its uids/gids.  (E.g., it may have set all its uids to zero)

You could, of course, bracket all such environment variable use with
seteuid()/setegid() in the library, but that isn't fullproof.

I think it just goes to show that environment variables have little business
in library code, they should be very limited.

Reading restricted file is not that much of a problem as long as you keep
the contents of the files secret, i.e., don't print "root:<pw>:::": parse
error at line 1.  Validate your input (for $TZ and $TERMINFO/$TERMCAP,
validating input is pretty easy, $TZ and $TERM* will only reveal
information if it happens to be in the right format)

You should also never load dynamic code specified by environment variables,
unless when loading from system directories.

Casper