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>