bin/153600: Path length restrictions in mount/umount tools prevent filesystem mount/unmount

[Roger Leigh]

The following reply was made to PR bin/153600; it has been noted by GNATS.

From: Roger Leigh <rleigh at debian.org>
To: Bruce Evans <brde at optusnet.com.au>
Cc: freebsd-gnats-submit at freebsd.org, freebsd-bugs at freebsd.org
Subject: Re: bin/153600: Path length restrictions in mount/umount tools
	prevent filesystem mount/unmount
Date: Sat, 1 Jan 2011 18:54:04 +0000

 --to+bXLvrczl8f0V1
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Sun, Jan 02, 2011 at 05:13:16AM +1100, Bruce Evans wrote:
 > On Sat, 1 Jan 2011, Roger Leigh wrote:
 >
 >> t at mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64
 >>> Description:
 >> When mount is asked to mount a filesystem on a node whose absolute path =
 is longer than 85 characters in length, the mount fails.  Umount also fails=
  under some circumstances, though the testcase attached below doesn't show =
 this.
 >> ...
 >>> Fix:
 >> I suspect that the mount/umount tools are using a fixed-length buffer an=
 d/or are truncating the path at some point.
 >>
 >> The mount(2) manual page documents the max path length at 1023 character=
 s, and the maximum length of any single component at 255 characters.  These=
  limits have not been exceeded, unless the documentation is incorrect.
 >>
 >> The practical upper limit of 80-85 characters demonstrated in this bug r=
 eport is very low.  The documented [ENAMETOOLONG] limit in mount(2) is sens=
 ible, but does not appear to reflect the practical reality at the present t=
 ime.  If the 80-85 character limit could be eliminated to allow this to wor=
 k as documented, this would remove a significant limitation in the FreeBSD =
 system which is breaking software which requires longer paths to function.
 >
 > Mount name lengths are in practice limited to (MNAMELEN - 1) =3D 87.  See
 > <sys/mount.h>.  This isn't easy to fix, since MNAMELEN is in critical APIs
 > (mainly struct statfs).  struct statfs has already been changed once too
 > often.  MNAMELEN used to be (80 - 2 * sizeof(long)), which is 80 or 72,
 > but was changed to 88.  MNAMELEN is of course mentioned in statfs(2), but
 > it isn't mentioned in mount(2) because it doesn't apply to the actual mou=
 nt
 > operation but only to determining what is mounted using statfs(2).  The
 > buffer gets truncated at mount time by mount in the kernel copying the
 > file name to the statfs buffer with blind truncation.
 >
 > In practice, this means that you should never use the feature of mounting
 > pathnames with length between MNAMELEN and (PATH_MAX - 1), since it is too
 > hard to manage the resulting mountpoints.
 
 I see, thanks.  This does make things somewhat more complex to fix.
 
 As a longer term (rather than immediate) solution, could I suggest
 taking a look at the GNU libc/linux versions of the statfs structure in
 <bits/statfs.h>?  In this version, the fixed-length fields are entirely
 absent, and so the length limitations are a non-issue here.  Of course,
 the structures are not compatible, and the missing information would
 need to be obtained via other means such as getmntent of /proc/mounts
 (for example).  But, the getmntent interface is also equally
 unrestricted, so in practice on GNU/Linux this problem does not exist.
 
 
 Kind regards,
 Roger
 
 --=20
   .''`.  Roger Leigh
  : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
  `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
    `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
 
 --to+bXLvrczl8f0V1
 Content-Type: application/pgp-signature; name="signature.asc"
 Content-Description: Digital signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.9 (GNU/Linux)
 
 iEYEARECAAYFAk0feEwACgkQVcFcaSW/uEhzKgCfRUHtNiwnSjHt//aTpbXqQNSY
 AUEAoM+ODWdhnvMlyk6RMRMAXSKwfpIq
 =bMeU
 -----END PGP SIGNATURE-----
 
 --to+bXLvrczl8f0V1--