Date: Wed, 20 Mar 2013 09:22:47 -0700 From: Alfred Perlstein <bright@mu.org> To: Bruce Evans <brde@optusnet.com.au> Cc: arch@FreeBSD.org Subject: Re: Increase the mount path to MAXPATHLEN? Message-ID: <5149E257.7030906@mu.org> In-Reply-To: <20130320211433.F1007@besplex.bde.org> References: <20130319201145.GA19260@ambrisko.com> <20130320211433.F1007@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 3/20/13 4:14 AM, Bruce Evans wrote:
> On Tue, 19 Mar 2013, Doug Ambrisko wrote:
>
>> At work we use lots of chroots and mount things within those chroots
>> like dev, proc etc. so it looks like a running system. We also do
>> some trickery so that we chroot into different versions of FreeBSD
>> and pull in some of the native binaries so things like mount, ps etc.
>> work inside. We will also create chroots inside that. Since these
>> things live in home directories and mount points can be in various
>> tree's the mount points are getting pretty long. It seems that
>> checking before was weak and let some of these mount worked by accident
>> in prior versions of FreeBSD.
>
>> I'd like to bump the mount point to support a larger value then
>> MNAMELEN (88) and to some what avoid this problem in the future thought
>> we should just use MAXPATHLEN. I figure that once start hitting that
>> limit probably a bunch of things are going to pop up.
>
> The limited has been hittable for ~30 years, but rarely hit. If it were
> important, then it would have been expanded when statfs was expanded to
> support 64-bit sizes on 32-bit systems. Instead, the pathname arrays
> have shrunk a bit since 4.4BSD where they had size 90. Before that,
> bits of the pathnames were bitten off to make space for more important
> fields, and the array size was reduced to 80 in struct ostatfs. THe
> current struct statfs just unbites for these fields and expands back to
> size 80.
>
> Does using MAXPATHLEN even fix the problem? Absolute pathnames much
> longer than it can be constructed using relative paths starting in
> a deep directory, or symlinks. I think mount(2) handle relative paths,
> but mount(8) uses realpath(3) and the latter is almost necessary for
> making the pathnames returned by statfs() usable. realpath() is broken
> as designed. It repeats the design errors of getwd() and only supports
> pathname lengths of < {PATH_MAX}. This "fixes" the problem that the
> path length might be longer than that by not supporting such paths.
>
> NetBSD "fixed" this long ago by keeping struct statfs unchanged but
> deprecated, but using _VFS_MNAMELEN = 1024 in struct statvfs. In
> FreeBSD,
> statvfs() and struct statvfs are just minimal compatibility cruft, with
> no names at all in the struct since names are nonstandard.
This is the approach I would hope to see happen. Making a separate
syscall/method to return a MAXPATHLEN mount path based on fsid would be
very easy and result in a lot less compat cruft.
I think it's time to deprecate retrieval of the mount paths via statfs
and instead use another call as do most other unix-like OSes.
-Alfred
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5149E257.7030906>