Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!husc6!bu-cs!madd
From: madd@bu-cs.BU.EDU (Jim Frost)
Newsgroups: comp.unix.wizards
Subject: Re: NFS security
Message-ID: <24792@bu-cs.BU.EDU>
Date: 9 Sep 88 02:28:38 GMT
References: <126@leibniz.UUCP> <670028@hpclscu.HP.COM> <1394@basser.oz> <1202@luth.luth.se> <66897@sun.uucp>
Reply-To: madd@bu-it.bu.edu (Jim Frost)
Followup-To: comp.unix.wizards
Organization: Boston University Distributed Systems Group
Lines: 36

In article <66897@sun.uucp> guy@gorodish.Sun.COM (Guy Harris) writes:
|> On all SunOS that I have access to (3.2, 3.5, 4.0) I got this when I try.
|> 
|> mknod: must be super-user
|> 
|> So it is a NFS problem.
|
|since the
|reason the "mknod" command prints that message is that it contains the lines
|
|	if(getuid()) {
|		fprintf(stderr, "mknod: must be super-user\n");
|		exit(2);
|	}
|
|which certainly have nothing whatsoever to do with NFS.  In fact, those lines
|came from the System V "mknod", and were added when named pipes were added to
|SunOS, because we picked up the S5R2 "mknod" command as part of the changes to
|add named pipes.  They are, in fact, in the S5"R1" "mknod", which antedates NFS
|by several years, so they clearly have nothing whatsoever to do with NFS.

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.

[Note that the mknod system call can be invoked by non-superusers only
for the creation of FIFO special files.]

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.

jim frost
adt!madd@bu-it.bu.edu