RELENG_8 -- NFSv3 credentials/permissions issue

[Jeremy Chadwick]

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.

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

But the above (and below, see tcpdump) files are not attempting to be
removed nor written to -- they're attempting to be read.

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

-- 
| Jeremy Chadwick                                   jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |