From owner-freebsd-stable@FreeBSD.ORG Sun Feb 21 11:52:34 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC335106566B for ; Sun, 21 Feb 2010 11:52:34 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id A17F68FC15 for ; Sun, 21 Feb 2010 11:52:34 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1NjAMT-000ATg-6G; Sun, 21 Feb 2010 13:52:33 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Jeremy Chadwick In-reply-to: <20100221102404.GA52396@icarus.home.lan> References: <20100219191102.GA1045@icarus.home.lan> <20100221074606.GA49241@icarus.home.lan> <20100221102404.GA52396@icarus.home.lan> Comments: In-reply-to Jeremy Chadwick message dated "Sun, 21 Feb 2010 02:24:04 -0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 21 Feb 2010 13:52:33 +0200 From: Daniel Braniss Message-ID: Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_8 -- NFSv3 credentials/permissions issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2010 11:52:35 -0000 > 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