NFS security

[Guy Harris]

> > >Well what happens if on SunOS 3.5 you do as root on your
> > >workstation on a remote fs
> > >mknod ~mydir/mem c 3 0
>
> > >yup, you end up with a nobody owned copy of /dev/mem.
> >
> >This is not an NFS problem, since it is equally applicable to
> >non-superusers on a local machine: it is simply a hint that
> >mknod should be root-only. :-)
> 
> This is not a problem in the System V.2 world. Not only does mknod.c
> check for superuser (easily bypassable) but mknod(2) does not allow
> anyone but root to mknod anything but FIFO's.

1) mknod(2) is super-user only, except when asked to create FIFOs, in *every*
   version of UNIX I know of.  It's hardly just S5R2....

2) The problem cited *is* an "NFS problem", in the sense that the UID mapping
   performed by the usual NFS implementations is its cause.  If "non-superusers
   on a local machine" were permitted to create special files other than FIFOs
   with "mknod", the files wouldn't be owned by "nobody" unless somebody did
   more than just removing the super-user check in "mknod" when they changed
   UNIX to allow non-superusers to create such files.

   Any remote file system where you do UID mapping will potentially have this
   problem, unless it doesn't map creator UIDs.