[ On Monday, November 13, 2000 at 08:30:09 (-0800), Bill Studenmund wrote: ]
> Subject: Re: Addition to force open to open only regular files
>
> The point is that by the time you can do the fstat(), for a number of
> things, IT IS TOO LATE.
> 
> The cacnonical example is s set-uid-root program being tricked into
> opening a rewind-on-open tape drive node. It's not the only one (though it
> is the biggest concern).

Besides with such broken device drivers and unfounded concerns, what
other things?

Of course if a privileged process read()s, or worse write()s, to a file
accidentally then there can be real problems, be it a device or not!
 
> The only way to prevent a race condition and keep from tickling on-open
> semantics is to make the check in open(2). That's the only point were we
> have done the path lookup and locked the node and haven't done the
> VOP_OPEN().

Perhaps....

So far two slightly unrelated features for open() have been proposed,
neither of which concretely solves any real problems that cannot already
be solved by other (albiet sometimes less elegant) means.

The real problem with $HOSTALIASES is that it can trick a privileged
program into opening a file.  The most elegant fix is to turn off that
feature.  I haven't knowingly used $HOSTALIASES in nearly a dozen years
and I've certainly never missed it, so perhaps it should be just ripped
out completely.  Certainly a set-id program should blatantly ignore it.

In general library routines that can be tricked into tickling arbitrary
files (eg. when an environment variable tells them to) are a bad thing
to combine with any set-id program.

Indeed given the growing importance of name-to-address mapping in the
things we use computers for, it could easily be argued that host naming
must be one of the most closely guarded administrative tasks!  Allowing
the user to trick a privileged program into talking to the wrong host
might be just as dangerous as having it open the wrong file!  In
distributed computing environments trusted hosts are often just as
important as trusted files.  Unfortunately trust is so much harder to
define in a distributed system, and indeed it is sometimes far harder to
discover the impact of such trust relationships after the fact!

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>