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 -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120129113158.4606.90...@thinkbox.jade-hamburg.de