Subject: Re: Addition to force open to open only regular files
To: NetBSD Kernel Technical Discussion List <tech-kern@netbsd.org>
From: Greg A. Woods <woods@weird.com>
List: tech-kern
Date: 11/21/2000 12:29:20
[ On Tuesday, November 21, 2000 at 12:47:43 (+0200), Alan Barrett wrote: ]
> Subject: Re: Addition to force open to open only regular files
>
> If we are thinking of new syscalls, then I think that
> open_if_stat_matches() would be more useful than open_as().  It
> would be used like this: stat(path, statbuf); check attributes in
> statbuf; open_if_stat_matches(path, statbuf, flags, mode).  There
> is no race vulnerability between stat() and open_if_stat_matches()
> because the kernel would refuse to open the file if the results from
> fstat() after the open would be different from the results of stat()
> before the open.  There should probably be a way of saying that
> certain fields in the stat structure (such as access time) are not
> important.

That's *way* more complicated than necessary and I'd even go so far as
to say that it's rather un-Unix-like too.

The purpose of access() is simply to see if the the file would be
accessible in some given way (read, write, execute) if the real user
were to try to open or execute the file.  To do this in one system call
(and thus clearly and explicitly eliminate any possibility of a race
condition) does not require even the mode to be passed since the open
flags themselves already provide this information.  [Of course open_as()
doesn't solve the problem of exec() running programs the user wouldn't
normally be able to run, but that's a somewhat different side to the
problem that's not necessarily of immediate concern.]

I say it's un-Unix-like because the added complexity doesn't really
solve any additional problems, at least none that I can think of and
none that anyone has yet shown.

Furthermore it still makes the application programmer jump through an
extra hoop that the kernel's just going to have to re-do itself anyway.

If you're trying to open the file then you may as well forget about
doing silly checks ahead of time and just try to open the damn file!
You'll find out soon enough if permissions don't allow it to happen.

The only thing unique here is that when you've got two different sets of
possible credentials to use for the open it is sometimes necessary to
tell the kernel which one to use for a particular open.

Clarity and simplicity are rather critical things to keep in mind when
designing interfaces that must be used in security sensitive programs.

> Note that an open_as() library function could be implemented using
> an open_if_stat_matches() syscall.

Yes, given some assumptions about the API are true, but of course at the
expense of an extra system call and a bit of storage.

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