Path: utzoo!utgpu!attcan!uunet!seismo!sundc!pitstop!sun!gorodish!guy
From: guy@gorodish.Sun.COM (Guy Harris)
Newsgroups: comp.unix.wizards
Subject: Re: NFS security
Keywords: NFS, mknod
Message-ID: <66806@sun.uucp>
Date: 2 Sep 88 20:13:04 GMT
References: <126@leibniz.UUCP> <670028@hpclscu.HP.COM> <1394@basser.oz> <4477@ptsfa.PacBell.COM>
Sender: news@sun.uucp
Lines: 26

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