Re: [patch] build fix for HURD

[Pavel Roskin <proski gnu org>]

Hi, Marcus!

> > > The patch is wrong.  PATH_MAX is not defined for a reason.  There is no
> > > upper limit for the path length on GNU/Hurd.

Finally I have committed the fix.  ".order" files are used to set the
order of entries for GNOME applications.  PATH_MAX (4095 in Linux) is
clearly on overkill.  MC uses a 1024-bytes long buffer now.

> > Yes. Therefore, you have to define it, when the Hurd doesn't set it, but
> > MC uses the value, right?
>
> Well, Pavel is correct.  Except I didn't bother to fix it properly, as I
> understood it that gmc is not actively maintained anyway, and sort of being
> phased out.

Yes, sort of.

> A proper patch which deals with arbitrary filenames is always preferred, I
> was just being very lazy in this case.

That's correct.  There is not way to exploit it, and menu items with more
than 1024 characters shouldn't be used, since it's not user-friendly :-)

> > > Note that the buffer in
> > > get_presorted_from() is allocated on the stack - exceeding it means crash
> > > in the best case or an exploit if a malicious user prepares `.order' for
> > > you.
>
> Mmmmh.  The main stack of a task is unlimited, isn't it?  If you use
> threading, on the Hurd each thread gets a fixed size thread, though.

I meant a stack overflow, now so popular thanks to Code Red.  But I was
confusing fgets() and gets() - the former is not _so_ unsafe, although it
has its own issues (no reliable way to determine string length if '\0'
appears in the input, see info libc).

-- 
Regards,
Pavel Roskin