Re: [bug #28446] No checks are made for unteminated strings in RPC messages

[Carl Fredrik Hammar]

Hi,

On Mon, Jan 04, 2010 at 03:34:07PM +0100, olafBuddenhagen@gmx.net wrote:
> On Sun, Jan 03, 2010 at 09:40:43PM +0100, Carl Fredrik Hammar wrote:
> > I still don't see how changing MIG is invasive...
> 
> As I said, it requires someone to say, "yes, this is the right thing to
> do; please commit".

Yes, but this isn't /invasive/ IMHO.

> On a technical side, you have to decide what error code MiG should
> return in this case. I don't think there is any appropriate one yet,
> which means you will have to add a new one, and make clients cope with
> it... That's what I mean by invasive -- it could have far-reaching
> consequences.

This would be invasive, but luckily there's already the MIG_BAD_ARGUMENTS,
which is used in all other failed server-side type checks.

> Not saying though that it shouldn't be done nonetheless... :-)
> 
> BTW, if someone actually does take a stab at that, I think it would be
> nice to also look into proper, not size-limited string support at the
> same time... AIUI, the way it is handled now, the claim that Hurd has no
> arbitrary limitations of file name size etc. is simply a lie.

Oddly, MIG supports fixed, variable, and unbounded size arrays, which
means that the size is always the same, always less then some limit,
or has no limit, but for some reason c_strings cannot be declared
unbounded...

Technically, you can look up a path of arbitrary length using the existing
RPC interface, you just have to do it in multiple steps.  Of course,
glibc doesn't do anything to break it up, so effectively we do have
PATH_MAX=1024 :-/  Of course, fixing MIG might actually be easier.

It does limit the length of a single component in the path though,
but again glibc already places tighter limits in the dirent structure
by using a 256 long char array when listing directories.  So there's a
lot more to this then just fixing MIG.

Regards,
  Fredrik