Subject: Re: devfs (was Re: Not updating device file inode change times)
To: Stefan Grefen <grefen@hprc.tandem.com>
From: Todd Vierling <tv@pobox.com>
List: tech-kern
Date: 09/06/1998 23:46:16
[thread copied to tech-security since I'm explaining the pitfalls of a
NFS-mounted /dev]

On Sun, 6 Sep 1998, Stefan Grefen wrote:

: > Real
: > device nodes on a NFS-mounted /dev are, as said before, dangerous and a
: > serious security risk.
: 
: But than a file just doesn't help here, or you have to authenticate the file
: with secret  ...

Authentication isn't the problem.  The problem is device nodes which have
the "wrong" major and minor on the NFS _server_.

Just a straw example:  You log into a NetBSD/arm32 NFS client on the
console.  The NFS server is NetBSD/alpha.  So the arm32 client's
/dev/console, device 2,0, becomes your uid and readable and writable by you.  
Log into the alpha server and do reads from /export/somebox/dev/console, and
be very surprised by the fact that you're reading the Alpha's /dev/mem!  
(Remember that the device node is also _writable_ by your uid.)

This device number inconsistency is a bug in the _best_ case.  When you
bring non-NetBSD systems into the picture, it's just plain dumb.

One way of helping is by providing a mechanism by which plain files on the
NFS server can become device nodes - sort of like a "rose colored
sunglasses" layer filesystem.  The filesystem would just translate files via
some not yet determined mechanism, both on read/write and inode
creation/modification.

I'm actually quite surprised to learn that our NFS implementation doesn't
support a `nomknod' export option, either.  I'm submitting a PR on that one.

-- 
-- Todd Vierling (Personal tv@pobox.com; Bus. todd_vierling@xn.xerox.com)