RELENG_8 -- NFSv3 credentials/permissions issue
Daniel Braniss
danny at cs.huji.ac.il
Sun Feb 21 11:52:35 UTC 2010
> On Sun, Feb 21, 2010 at 12:02:28PM +0200, Daniel Braniss wrote:
> > > I'm not sure if you're referring to NFS here, or my TFTP comment. My
> > > TFTP comment should be discussed elsewhere -- it's broken/odd behaviour,
> > > but the workaround for TFTP (to set the file permissions to 0644 for
> > > read) I'm fine with -- it's TFTP! :-)
> > >
> > if the owner does not have read permition, it wont be able to read the file,
> > no matter that the other read bits are enabled.
> >
> > % date > 0
> > % chmod 04 0
> > % cat 0
> > cat: 0: Permission denied
> > % chmod 040 0
> > % cat 0
> > cat: 0: Permission denied
> > % chmod 0400 0
> > % cat 0
> > Sun Feb 21 11:47:32 IST 2010
> > %
> > this answers the TFTP problem.
>
> Actually it doesn't. Are you familiar with C? If so, have a look at
> this piece of the source code (src/libexec/tftpd/tftpd.c):
>
> 586 int
> 587 validate_access(char **filep, int mode)
> 588 {
> ...
> 618 if (stat(filename, &stbuf) < 0)
> 619 return (errno == ENOENT ? ENOTFOUND : EACCESS);
> 620 if ((stbuf.st_mode & S_IFMT) != S_IFREG)
> 621 return (ENOTFOUND);
> 622 if (mode == RRQ) {
> 623 if ((stbuf.st_mode & S_IROTH) == 0)
> 624 return (EACCESS);
> 625 } else {
> 626 if ((stbuf.st_mode & S_IWOTH) == 0)
> 627 return (EACCESS);
> 628 }
> ...
> 694 return (0);
> 695 }
>
> This function is called whenever there's a request of any sort via TFTP
> (such as file retrieval (read) or file storage (write)). In this
> context, RRQ = "read request".
>
> The above code explicitly requires the global/other read (or write, if
> the request is to write data) bit be set on the files being
> requested/written to, otherwise EACCESS ("Access Denied") is returned to
> the client. This is *regardless* of who owns the file. See the stat(2)
> man page for verification of S_IROTH and S_IWOTH bits.
>
> This is justified *unless* UID switching is present -- meaning, if the
> -s option (and/or -u) is used. If -s is used but no -u is specified,
> the daemon switches to user "nobody" by default. But regardless of what
> user the daemon switches to, its code still explicitly requires the
> global read or global write bits be set on the files.
>
> IMHO, the above permissions checks should be removed if -s is in effect.
>
the code is only usefull if running as root (and questionable too).
I agree, the code is useless, it should use access(2), but tftpd predates it
:-(
> > > With regards to NFS: none of the files below are mode 0000. The request
> > > made via NFS should have gotten "translated" to being done by
> > > nobody:nobody on the NFS server, since there's no -mapall or -maproot
> > > line in the exports; user nobody has read access to everything shown
> > > below, so "Permission denied" makes no sense.
> > >
> > as I mentioned before/above, maybe not so clearly, the initial NFS transactions
> > are done via NFS/V2 - which is problematic/broken[1], and so probably
> > the access permitions are not exactly what we expect.
> >
> > [1]: rm /any-file in a read-only exported fs will hang the client
> >
> > > > > Permissions
> > > > > =============
> > > > > drwxr-xr-x 22 root wheel 512 Feb 6 12:25 /
> > > > > drwxr-xr-x 17 root wheel 512 Feb 12 03:38 /usr
> > > > > drwxr-xr-x 15 root wheel 512 Feb 19 10:41 /usr/local
> > > > > drwx------ 5 nobody nobody 512 Feb 19 10:42 /usr/local/freebsd8
> > > > > drwx------ 7 nobody nobody 1024 Nov 21 08:11 /usr/local/freebsd8/boot
> > > > > drwx------ 2 nobody nobody 12800 Nov 21 08:11 /usr/local/freebsd8/boot/kernel
> > > > > -r-------- 1 nobody nobody 11492703 Nov 21 07:48 /usr/local/freebsd8/boot/kernel/kernel
>
> Okay, so then you're saying it's a bug of some sort in NFSv2, not NFSv3.
>
yes
> But the above (and below, see tcpdump) files are not attempting to be
> removed nor written to -- they're attempting to be read.
I mentioned the rm bug to show that there is at least a well known problem, and
your problem seems to point to yet another one.
> Should I file a PR for this problem? IMHO, it's a pretty serious
> oversight (it effectively means user/group ownership means jack squat
> with NFSv2).
well, V2 is quiet dead, and I doubt anyone is willing to look into it,
what would be nice if pxeboot is upgraded to use NFS/V3 - before it becomes
obsolete too :-)
danny
More information about the freebsd-stable
mailing list