Re: Thoughts on MAXPATHLEN
Hello! 2012/1/31 Jérémie Koenig j...@jk.fr.eu.org: On Tue, Jan 31, 2012 at 12:57 PM, Justus Winter teyth...@jade-hamburg.de wrote: Well, fixing fixed-sized buffer issues is a good exercise to improve ones c skills, And not only C skills. During the process you learn a lot about Hurd, Debian and some useful stuff like git, valgrind, ikiwiki... It's not only fixing a bug but understanding all the ecosystem. This is actually the reason why it took me so long to start contributing! :-( but I do not see how it helps anyone to get a foot into the Hurd project if he fixed a bug in e.g. nautilus or tar. I do agree. Fixing PATH_MAX code should not be the Hurd developer's job! We could decide to define PATH_MAX in Hurd limits.h or create #define PATH_MAX patches for all the packages for the time being and we would have 200+ new packages available on Hurd. But then those packages will never be fixed because nobody will ever have time to fix something that already works! And we will end up with a broken OS... which we already have! ^_^' But it's my humble opinion! And I quite happy fixing trivial bugs for now! :-) Fixing real problems related to Hurd, gnumach, mig, the documentation and Debian or Arch integration and packaging is much more helpful for both Hurd users and the project itself. Not everyone can fix complex bugs or work on Hurd internals. Fixing trivial bugs is something that I can do when I have time without bothering (too much) the real developers. So, what ever you guys decide to do... count me in! ^_^' Tanguy -- 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/CAJbrmLDYCvZX+oQhFRH0ia8wa8_6o2__ZS7=p0wxot-uofe...@mail.gmail.com
Re: Thoughts on MAXPATHLEN
Tanguy LE CARROUR, le Fri 03 Feb 2012 11:34:47 +0100, a écrit : I do agree. Fixing PATH_MAX code should not be the Hurd developer's job! We could decide to define PATH_MAX in Hurd limits.h or create #define PATH_MAX patches for all the packages for the time being and we would have 200+ new packages available on Hurd. With very high probability of having buffer overflow issues. Hiding a bug is never a good solution. Fixing real problems related to Hurd, gnumach, mig, the documentation and Debian or Arch integration and packaging is much more helpful for both Hurd users and the project itself. Not everyone can fix complex bugs or work on Hurd internals. There are non-complex things to do there too. See the thread about the keymap support on the mach console. Yes, that *is* a non-complex thing to do. Just try. And you'll learn a lot alongside. Samuel -- 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/20120203113918.gc4...@type.bordeaux.inria.fr
Re: Thoughts on MAXPATHLEN
2012/2/3 Samuel Thibault sthiba...@debian.org: With very high probability of having buffer overflow issues. Hiding a bug is never a good solution. I totally agree! But as Justus showed those overflow problems exist on Linux. Hurd is the only OS that doesn't hide them, which I think is a good think. Would it be possible to send some e-mails to all the developers of the related packages explaining why and how they should fix it!? Maybe not all 200+ packages would be fixed, but I'm pretty sure some developers would be happy to fix their package! ... And I'm volunteering to fix the rest! ^_^' ... just kidding... Not everyone can fix complex bugs or work on Hurd internals. There are non-complex things to do there too. See the thread about the keymap support on the mach console. Yes, that *is* a non-complex thing to do. Just try. And you'll learn a lot alongside. I think I'll give it a try, when I'm done with PATH_MAX! ^_^' Tanguy -- 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/cajbrmlc+wamar6_7jwp8ywcumoenog7a8jfnkf8xehanmh3...@mail.gmail.com
Re: Thoughts on MAXPATHLEN
On Sun, Jan 29, 2012 at 11:31:58AM -, Justus Winter wrote: 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. Without mentioning there is at least a system out there on which the issue is present, upstream will probably just ignore the request. 2. Define MAXPATHLEN and work on more important issues. Why not do both ? Fixing those issues is a good way to get a first foot in the project. -- Richard Braun -- 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/20120131085958.ga9...@mail.sceen.net
Re: Thoughts on MAXPATHLEN
Quoting Richard Braun (2012-01-31 09:59:58) On Sun, Jan 29, 2012 at 11:31:58AM -, Justus Winter wrote: 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. Without mentioning there is at least a system out there on which the issue is present, upstream will probably just ignore the request. My point was that there is a system that has those issues, and that system is Linux (and Hurd, and probably all of the BSDs too). 2. Define MAXPATHLEN and work on more important issues. Why not do both ? Fixing those issues is a good way to get a first foot in the project. Well, fixing fixed-sized buffer issues is a good exercise to improve ones c skills, but I do not see how it helps anyone to get a foot into the Hurd project if he fixed a bug in e.g. nautilus or tar. Fixing real problems related to Hurd, gnumach, mig, the documentation and Debian or Arch integration and packaging is much more helpful for both Hurd users and the project itself. Justus -- 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/20120131115702.23430.64...@thinkbox.jade-hamburg.de
Re: Thoughts on MAXPATHLEN
On Tue, Jan 31, 2012 at 12:57 PM, Justus Winter teyth...@jade-hamburg.de wrote: Well, fixing fixed-sized buffer issues is a good exercise to improve ones c skills, but I do not see how it helps anyone to get a foot into the Hurd project if he fixed a bug in e.g. nautilus or tar. A social foot maybe, but otherwise I agree. Fixing real problems related to Hurd, gnumach, mig, the documentation and Debian or Arch integration and packaging is much more helpful for both Hurd users and the project itself. Right. For what it's worth, I'm personnaly agnostic with regards to defining PATH_MAX on Hurd. -- Jérémie Koenig j...@jk.fr.eu.org http://jk.fr.eu.org/ -- 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/ca+kcsaa6g4svzjvftgg7sgpsxgc+k4rqiak3moxjajljx1f...@mail.gmail.com
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 -- 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
