Date: Sun, 21 Feb 2010 02:24:04 -0800 From: Jeremy Chadwick <freebsd@jdc.parodius.com> To: Daniel Braniss <danny@cs.huji.ac.il> Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_8 -- NFSv3 credentials/permissions issue Message-ID: <20100221102404.GA52396@icarus.home.lan> In-Reply-To: <E1Nj8dw-0009FM-U1@kabab.cs.huji.ac.il> 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>
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.
> > 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@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100221102404.GA52396>