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

[olafBuddenhagen]

Hi,

On Thu, Jan 07, 2010 at 04:45:57PM +0100, Carl Fredrik Hammar wrote:
> 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.

If it wasn't invasive, approving it would be a no-brainer :-)

> > 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.

OK.

Still, there might be other implications...

> Technically, you can look up a path of arbitrary length using the
> existing RPC interface, you just have to do it in multiple steps.

Right...

> Of course, glibc doesn't do anything to break it up, so effectively we
> do have PATH_MAX=1024 :-/

It's even more confused in fact: If you have retries in between, you can
actually use much longer paths... Only if a *single* server has to
handle longer filename pieces, it breaks.

> Of course, fixing MIG might actually be easier.

Not sure whether it would be easier... But it definitely does seem the
right thing to do.

The "XXX" comment on the definition of string_t indicates that it *was*
meant to be temporary only.

> 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.

Indeed. This is less obvious, as actual disk filesystems have limits on
that anyways... But it would be nice at least for virtual filesystems
not to have such limitations.

(Whether it's worthwhile creating disk filesystems without such a
limitation is another can of worms...)

BTW, there is no macro for the maximal length of a single file name
component, is there?... I guess that would have been too useful, as it
actually matches reality ;-)

-antrik-