Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!oliveb!sun!gorodish!guy
From: guy@gorodish.Sun.COM (Guy Harris)
Newsgroups: comp.unix.wizards
Subject: Re: NFS security
Message-ID: <67592@sun.uucp>
Date: 9 Sep 88 06:43:03 GMT
References: <126@leibniz.UUCP> <670028@hpclscu.HP.COM> <1394@basser.oz> <24792@bu-cs.BU.EDU>
Sender: news@sun.uucp
Lines: 46

> You're correct in that the error has nothing to do with NFS, but mknod
> will not allow anyone but the superuser to create files *at the system
> call level*.  Even if mknod(8) didn't have the check you describe, the
> call would fail later in the program when mknod(2) was issued.

Yes, I'm quite aware of that; that's why I stated that I had no idea what the
check was doing in the "mknod" command.  The only effects the check in the
command has are:

	1) since the check is done before the check for "argc != 5" in the S5
	   version if a non-superuser forgets what the syntax is for creating
	   FIFOs, they can't just type "mknod" and get a usage message (this is
	   done right in the Sun version).

	2) the error message you get if you're not super-user is

		mknod: must be super-user

	   rather than

		mknod: Not owner

	   which is a more useful message.  This is the only reason I can see
	   for sticking the check in.  (The "correct" fix for this would be to
	   add a new error code, so that you can distinguish between "you can't
	   do that to the object in question because your effective user ID is
	   not that of the owner of the object nor is it superuser", which
	   would give the message "Not owner", and "you can't do that because
	   you're not superuser", which would give the message "Not
	   super-user".  The two are distinct errors, but unfortunately are
	   both reported with the same error code EPERM.  It is, alas, a bit
	   late to fix UNIX's overloaded error codes....)

> Another thing to be wary of is "superuserness" does not carry over NFS
> connections, thus if you were root on the local system and tried to
> issue mknod for a NFS filesystem, you might get the same style of
> error.  This would, in fact, be a problem with NFS.  But most people I
> know call it a feature.

The problem, as originally stated, is that the superuserness is irrelevant once
the operation goes over the wire, in most UNIX NFS servers; the server does not
forbid remote "mknod"s, even if 0 is mapped to -2.  The check is done at the
system call level, so neither the NFS server code nor the underlying UNIX file
system code that the server calls does the check.  The check should be done in
the underlying file system code, and not at the system call level (after all,
somebody might want to implement a file system on which non-superusers *can* do
arbitrary "mknod" operations).