On Fri, 10 Nov 2000, Greywolf wrote:

> On 10 Nov 2000, Nathan J. Williams wrote:
> 
> # > Thoughts?
> # 
> # ``Yuck''.
> 
> Agreed.
> 
> If you're concerned about the type of file you're opening, OPEN the thing
> and then fstat(fd) it.  If it's not the right type, act appropriately,
> whether that means looping on trying to open something (based on user
> input) or abort and bitch.

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

The problem with fstat()'ing is that by the time the open(2) call returns,
we've lost. Closing the descriptor at that point does nothing. We could
even just have fd = open(); close(fd); and we've lost.

"stat() before you open()" some might say. Well, then we have a race
condition.

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().

> It is not (always) the responsibility of the OS to solve the programmer's
> security issues.

I agree.

But how else can we solve this problem withouth opening up a race
condition? From what I can see, the kernel is the only place where we can
close this hole.

Take care,

Bill