From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [PATCH 25/28] VFS: statfs(64) shouldn't follow last component symlink Date: Mon, 25 Oct 2004 16:14:05 +0100 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <20041025151405.GA1740@infradead.org> References: <10987158413464@sun.com> <10987158711277@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, raven@themaw.net Return-path: Received: from phoenix.infradead.org ([81.187.226.98]:59148 "EHLO phoenix.infradead.org") by vger.kernel.org with ESMTP id S261922AbUJYPOF (ORCPT ); Mon, 25 Oct 2004 11:14:05 -0400 To: Mike Waychison Content-Disposition: inline In-Reply-To: <10987158711277@sun.com> List-Id: linux-fsdevel.vger.kernel.org On Mon, Oct 25, 2004 at 10:51:11AM -0400, Mike Waychison wrote: > Mount-related userspace tools will require the ability to detect whether what > looks like a regular directory is actually a autofs trigger. To handle this, > tools can statfs a given directory and check to see if statfs->f_type == > AUTOFSNG_SUPER_MAGIC before walking into the directory (and causing the a > filesystem to automount). > > To make this happen, we cannot allow statfs to follow_link. > > NOTE: This may break any userspace that assumes it can statfs across a > last-component symlink. I can't think of any real world breakage however, as > mount(8) will drop the real path in /etc/mtab and /proc/mounts will always > show the true path. Which means it's vetoed. It's a big change in syscall semantics. And propabably breaks SuS (for statvfs(3) which requires full symlink resolution when it just refers to a path on the filesystem.