Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp3378365pxb; Mon, 17 Jan 2022 19:03:56 -0800 (PST) X-Google-Smtp-Source: ABdhPJzW6NLLf1/fKEEWQ5YfjBoPk+nAb3/kxGwCf3ZQtjOVUXj569tvkbnVChOau7e6NFwRsvAZ X-Received: by 2002:a17:90b:38c9:: with SMTP id nn9mr15949375pjb.219.1642475036298; Mon, 17 Jan 2022 19:03:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1642475036; cv=none; d=google.com; s=arc-20160816; b=mkRwnrBtdbSSk04GLT3CFNKWYCHVkyR45v6LUt/xFTUnOYpCUrb306ROdR7UhdgdK2 9cOe0UBSAKAXjrrtEyN9G3klLYeuJY+XvjDjmpmXeLqR6TkcQH6pH8HHkiKf43exy11v 0QLxFgxLidh8f3JTLOmTNbvh/l0BOoVdxVhwtgpAFoQkECATLFqsXErh1QJGNbYIKEUV QAKHIQFgcRWQipWxbD4lAh34wwwOZljwC+mXJZ65B8jIgNq+pGSsbx5IsHP/vVrIFG4s Vi8pLk3qNQutGXsmhi9WeMi+hEfyuSPVkDNWI8d4OYBHQNoZ1bjR1ElGTpp1Jjx44npT kjbA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature:dkim-filter; bh=HWXOySzTesOCkNmgc0zsrIXi2KkHFJTM8RONB7hMfdY=; b=r9CJbU5UCGgnB93nEMgHSsX0YFvY1EezQ72gTYoMjnjI0hkh7snC2QTjqY8clzZUiQ dTlL5e7TwMjcv1MI3PzKVzYrjq9NNM/Gw9gHvtBUWmPdMtR6Ykjx+VjQMWxuYrowBLDF 34oghMSyJ6r5es3jQBw2Ty7yChLPi/54r9BOsmdIc2CYcc+tJX3QqW0G/3GJ/+EX7DMY 8XRFWR7I243s44SFdYSu/rj9ujZRMrBQTp9sqpGybprhZiluYRre/eyGIfRU1rxzgnM6 NNTT9wjMR5EXymfJcahYOHu3zUJfv1+P5X6mTbLScjEDvtigUL4fE9XexZhvg+8FBFP4 PPsw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@fieldses.org header.s=default header.b=gs1CrRkQ; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f17si10681103pfv.159.2022.01.17.19.03.31; Mon, 17 Jan 2022 19:03:56 -0800 (PST) Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@fieldses.org header.s=default header.b=gs1CrRkQ; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243645AbiAQWh7 (ORCPT + 99 others); Mon, 17 Jan 2022 17:37:59 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36076 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232161AbiAQWh6 (ORCPT ); Mon, 17 Jan 2022 17:37:58 -0500 Received: from fieldses.org (fieldses.org [IPv6:2600:3c00:e000:2f7::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C2C53C061574 for ; Mon, 17 Jan 2022 14:37:58 -0800 (PST) Received: by fieldses.org (Postfix, from userid 2815) id 8510D6214; Mon, 17 Jan 2022 17:37:57 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 fieldses.org 8510D6214 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fieldses.org; s=default; t=1642459077; bh=HWXOySzTesOCkNmgc0zsrIXi2KkHFJTM8RONB7hMfdY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=gs1CrRkQgG5aFqASU6pRgEEdjZJbIXpvuqCcm0K5bpQhLCCPbdTQtpB27P7EdZwCn AgL1jsX23Em+EP7TDboFyHb2qwfOzP63PxeDiAMEE/6ZF/zYwKAsPX0U+FM4tdV6oI tps798sS3OOUDgvgA4TUj53CAf6eBs1OvZ2KDvpg= Date: Mon, 17 Jan 2022 17:37:57 -0500 From: "J. Bruce Fields" To: Chris Chilvers Cc: linux-nfs@vger.kernel.org Subject: Re: [bug report] Resolving symlinks ignores rootdir setting Message-ID: <20220117223757.GC3090@fieldses.org> References: <20220114151022.GA17563@fieldses.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Fri, Jan 14, 2022 at 03:57:03PM +0000, Chris Chilvers wrote: > > I'm probably just reading too quickly, but I'm not seeing how this > > explains the problems with your original configuration. > > > > Is it that /sr/nfs/bin on you system is a symlink? (And what exactly is > > the content of that symlink?) > > No, all the directories under /srv/nfs are ordinary directories. The symlinks > are in the root of the real file system. Oh, got it, thanks for the explanation. > So I have: > /bin -> /usr/bin > /software -> /usr/lib (created to test the hypothesis) > /srv/nfs/ > /srv/nfs/assets > /srv/nfs/bin > /srv/nfs/software > > Because exportfs is not taking into account the rootdir setting, when it tries > to resolve the path from /etc/exports, it sees the path /bin, and matches that > with the real /bin, and resolves it to /usr/bin. > > Later exportfs errors when trying to resolve the real path (e_realpath) in the > exportent_mkrealpath function, as this function does prepend the rootdir. This > causes exportfs to look for /srv/nfs/usr/bin instead of the expected > /srv/nfs/bin. > > At best this causes an error, but if that does happen to match an existing path > under /srv/nfs then it would export the wrong directory. > > This will happen for any export that happens to match an existing symlink. > > There are two issues though that I'm not sure how best to handle: > * Should the symlink be considered relative to the local system or relative to > the rootdir? > * What happens if the symlink points to a directory outside the rootdir? Yes, I'm not sure off hand what the right behavior is, but the existing behavior certainly seems to violate the principal of least surprise. --b. > > In my case I think the symlink would need to be resolved relative to the > rootdir. This is because we're re-exporting an existing NFS server, so if the > existing NFS server is exporting some kind of symlink tree, the symlinks would > be relative to the existing mounts. > > One option that would be valid for my case would be an setting to disable > symlink resolution and just consider it an error if an export is a symlink. > Since I'm re-exporting an existing NFS server, they can't be symlinks anyway. > > -- Chris