Re: CVS commit: basesrc

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Mon, 01 May 2000 22:52:52 +0900
    From:        itojun%iijlab.net@localhost
    Message-ID:  <28451.957189172%coconut.itojun.org@localhost>

  |     basically, we can never allow fopen()
  |     in setuid'ed privilege here.

Which is supposed to be the problem?   Using stdio (and if so, just
in library routines that might be called by a setuid process?), or
doing the open of a user supplied file name?

If it is stdio, then I suspect there are lots more problems, but I
would need more details.   If it is opening the user supplied file that's
the problem, I would expect that writing the code carefully ought fix that.

  |     there are couple of ways to fix it:
  |     - disallow $HOSTALIASES for setuid'ed binary - the committed one

which means ping alias (or traceroute ...) no longer works.   This is not
good.   One of the uses for ping (etc) is to help find out why other
applications don't work - if it doesn't behave the same way, that is if
"ping foo" isn't going to find the same host as "telnet foo", then it
makes everything harder).

  |     - 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

Yes, that's hard to do safely.

  |     - open $HOSTALIASES in real uid, using some help from new
  |       openwithrealuid()-like system call - not sure if we want it now

Looks like overkill.

  |     - assume all users of DNS resolver function to drop setuid
  |       before calling any name resolution functions - NO WAY

No, I agree, no assumptions like that.

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

Then I'm glad I've been using NetBSD.

  |     the situation is much worse.

Would you like to explain the supposed problems?  Without knowing what
this is supposed it be fixing, it is hard to tell whether it is either
necessary or sufficient.

I know there's an issue with dealing with setuid(N) (N != 0) processes,
and reading HOSTALIAS files which are protected, but that can't be what
is of concern here (the fix suggested has the same effect).

Aside from that, being able to read a non-readable file is harmless,
unless the data is exposed, and that apparently isn't the problem.

About all that's left is the possibility of access to some file where
simply reading it changes things - which pretty much means sockets,
tapes, etc.   If that's the issue, then a "regular file only" flag to
open (O_REGULAR) seems like the right fix to me, and one quite easy to
add.

kre

ps: if the resolver functions have some problem here with HOSTALIASES,
don't the ctime() functions have the same problem with TZ ?  Or is it
proposed that setuid programs aren't going to be allowed to operate in
a non-standard timezone??