Thoughts on MAXPATHLEN
Hi fellow shepherds :)
I recently started playing around with the Hurd again and one of the
first things I do is to patch my pet editor so it builds and works on
the Hurd. It's a MAXPATHLEN issue and I always start with a trivial
patch that just defines it to see if it is the only issue, but once I
got a hacked up Debian package I move on to something more
interesting.
Anyhow, I recently played around with paths > MAXPATHLEN and
discovered the following:
1. Linux
I've got a Debian testing installation here:
% uname -a
Linux thinkbox 3.1.0-1-amd64 #1 SMP Tue Jan 10 05:01:58 UTC 2012 x86_64 GNU/Linux
% mount | grep thinkbox-var
/dev/mapper/thinkbox-var on /var type ext4 (rw,nosuid,nodev,noatime,errors=remount-ro,user_xattr,barrier=1,data=ordered)
% echo -e "#include <sys/param.h>\nMAXPATHLEN" | gcc -E -x c - | tail -n 1
4096
Linux happily creates paths longer than MAXPATHLEN (see recipe at the
end) and if you try to manipulate it or start programs with cwd >
MAXPATHLEN, things go really bad, e.g.:
* nautilus crashes b/c of unhandled signal 8, arithmetic exception
* tar can create an archive containing such paths, but cannot untar it
* filelight just ignores the path
* gdb refuses to work
(off topic: bonus points for anyone who finds a MAXPATHLEN related
buffer overflow in a commonly installed suid binary or a daemon
running as root that traverses a region of the vfs that unprivileged
users control and be sure to buy me a beer if you succeed ;)
2. Hurd
I tried to do the same on one of my Hurd installations and ended up in
/ with mkdir complaining that I'm not allowed to write to /.
Not sure what's going on here, but iirc the MIG string type is
bounded.
Some thoughts:
* Any software that does not dynamically allocate resources for path
manipulations is broken, even on systems that define MAXPATHLEN.
* So this is a problem that exists on Linux too, but it is obscured by
the fact that Linux just defines MAXPATHLEN to an arbitrary value.
* But the problem is more apparent on the Hurd since it chose not to
define MAXPATHLEN, resulting in an enormous amount of manual and
tedious work while porting packages.
* The Hurd community is way to small to carry the burden of fixing all
those issues and there are more important issues that need to be
addressed.
* It is sometimes difficult to get the patches upstream since Hurd
might be seen as an toy OS.
* It is very easy to create paths longer than MAXPATHLEN on Linux and
to crash / dos / evade programs using it and it might (can anyone
confirm this?) not even be possible to create paths of arbitrary
length on the Hurd b/c of a MIG limitation. But Hurd is the platform
that chose not to define MAXPATHLEN and Linux just lies to it's
users yet Hurd is perceived as the problematic one.
Based on this observations I'd vote to do the following:
1. File bugs for software that uses MAXPATHLEN and co, do so politely
and explain the issues. Talk directly to upstream and *do not*
mention the Hurd.
2. Define MAXPATHLEN and work on more important issues.
Well, flame on :)
Cheers,
Justus
~~~ recipe ~~~
to create such a path, do
% A=`python -c 'print 128 * "a"'`
% for i in `seq 40` ; do mkdir $A ; cd $A ; done
% pwd | wc --bytes
5169
to reenter it, do
% while cd $A ; do true ; done
Reply to: