From owner-freebsd-bugs@FreeBSD.ORG Fri Jun 20 20:59:53 2014 Return-Path: Delivered-To: freebsd-bugs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DC57DE87 for ; Fri, 20 Jun 2014 20:59:53 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A8EEC2A6E for ; Fri, 20 Jun 2014 20:59:53 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.8/8.14.8) with ESMTP id s5KKxru2063653 for ; Fri, 20 Jun 2014 21:59:53 +0100 (BST) (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 191218] mountd: can't change attributes for XXXXXXX: Invalid radix node head, rn: 0 0xXXXXXXXXXXXXXXX; can still mount path Date: Fri, 20 Jun 2014 20:59:53 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: yaneurabeya@gmail.com X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 20:59:53 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191218 --- Comment #5 from yaneurabeya@gmail.com --- (In reply to Xin LI from comment #4) > (In reply to yaneurabeya from comment #3) > > (In reply to Xin LI from comment #2) > > > Exporting subdirectories of a mountpoint is problematic and this is a well > > > known limitation of the protocol. I don't consider this as a security issue > > > because the administrator is supposed to know what they are doing. > > > > The security concern was over the fact that mountd is clearly reporting an > > error in the code, but hiding the fact that it's actually an error; unless > > the administrator is looking for errors from mountd, they have absolutely > > _no_ idea that the path is actually exported. > > mountd have (correctly) reported that it was unable to change the export > attributes, we could, of course, use better error message, but if the > administrator chooses to ignore error messages, there is nothing we can do > with it. > > Also, exporting subdirectories just plain doesn't work because the NFS > client can still request anything in the mountpoint. Properly implemented > client does not allow it but an attacker do not have to use a properly > implemented one. This is well known and relying on this security model is > just plain wrong. I forgot to include the fact that localhost:/tmp/bar was mounted to /mnt ; this was implied in my reproduction steps. /tmp/foo and /tmp/bar are two distinct paths. Why is /tmp/foo being exported if it's not showing up in showmount -e? Yes, I know that I've been playing in Linux for a little too long (9 months), and looking back I'm not using the prescribed syntax for exports(5), but I expected the code to not export /tmp/bar and it did. (posing the question differently) As a sysadmin/support engineer, how could I understand that mountd has actually exported the directory if the tools that should be doing this (showmount -e) don't print out anything meaningful? -- You are receiving this mail because: You are the assignee for the bug.