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

[olafBuddenhagen]

Hi,

On Sun, Jan 03, 2010 at 09:40:43PM +0100, Carl Fredrik Hammar wrote:
> On Sun, Jan 03, 2010 at 11:42:52AM +0100, olafBuddenhagen@gmx.net
> wrote:

> > But if Mach actually knows C strings, are you sure the kernel
> > doesn't actually perform the check for 0-termination itself in the
> > IPC code?...
> 
> Yes, I attached gdb to a translator receiving an unterminated string
> and the string was indeed unterminated on arrival.

OK.

> Also, I don't think Mach's IPC knows about C strings, only MIG.

Indeed it probably doesn't... I guess it's just a byte array at Mach
level. It wasn't clear to me what happens excatly from a quick glance --
and I have no time presently for a closer look :-(

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

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.

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.

-antrik-