Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 21 Feb 2010 13:52:33 +0200
From:      Daniel Braniss <danny@cs.huji.ac.il>
To:        Jeremy Chadwick <freebsd@jdc.parodius.com>
Cc:        freebsd-stable@freebsd.org
Subject:   Re: RELENG_8 -- NFSv3 credentials/permissions issue 
Message-ID:  <E1NjAMT-000ATg-6G@kabab.cs.huji.ac.il>
In-Reply-To: <20100221102404.GA52396@icarus.home.lan> 
References:  <20100219191102.GA1045@icarus.home.lan>  <E1Nj6CH-0005fP-Uh@kabab.cs.huji.ac.il> <20100221074606.GA49241@icarus.home.lan> <E1Nj8dw-0009FM-U1@kabab.cs.huji.ac.il> <20100221102404.GA52396@icarus.home.lan>

next in thread | previous in thread | raw e-mail | index | archive | help
> 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






Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1NjAMT-000ATg-6G>