Subject: Re: Addition to force open to open only regular files
To: Bill Studenmund <wrstuden@zembu.com>
From: Nathan J. Williams <nathanw@MIT.EDU>
List: tech-kern
Date: 11/10/2000 15:20:03
<wrstuden@zembu.com> (Bill Studenmund) writes:

> One of the things that came up in a recent security thread (how to use
> HOSTALIASES safely in a set-uid program) was that it would be nice for
> userland to be able to ask the kernel to only open a regular file. This
> ability is important as it means that untrusted path names ($HOSTALIASES
> for example) can't be used to open devices. Remember that some devices
> have implicit behaviors on open. Like certain tape nodes imply reqinding
> before open.
> 
> We want to be able to prevent that. We need to do it in the kernel,
> though, as part of the open. Otherwise we have to do two name lookups, one
> to see if the name is ok, and the next to open it. But that adds a race
> condition..
> 
> So here are patches which add a new open flag, O_REG_FILE, and add a test
> to the kernel after we've done the name lookup but before we've done the
> VOP_OPEN() to make sure we really got a regular file.
> 
> Thoughts?

``Yuck''.

1) This feels like it's solving the wrong problem. If there are issues
   with opening non-regular files that have side-effects on reading,
   then there will be issues opening regular files that the user
   shouldn't access, too.

2) Side effects on open are gross. What examples exist besides the
   tapes? 

3) Increases unportability and won't be reliably used by third-party
   code.

4) Lack of symmetry. If there's an O_REG_FILE, there should be an
   O_CHAR_DEVICE, an O_BLOCK_DEVICE, an O_DIRECTORY, ..... and this
   way of handling the issue quickly becomes unwieldly.

5) Personally, it seems like a lot of trouble and cruft for a feature
   that I've never used, or even heard of before its security issues 
   came up :)


        - Nathan