Remote root hole in Samba [LWN.net]

Remote root hole in Samba

Posted Apr 12, 2012 22:51 UTC (Thu) by nybble41 (subscriber, #55106)
In reply to: Remote root hole in Samba by endecotp
Parent article: Remote root hole in Samba

While that seems to be the intent, and the most common implementation, all I could find on the subject in the C99 draft standard is this:

> An integer may be converted to any pointer type. Except as previously specified, the result is implementation-defined, might not be correctly aligned, might not point to an entity of the referenced type, and might be a trap representation.

> Any pointer type may be converted to an integer type. Except as previously specified, the result is implementation-defined. If the result cannot be represented in the integer type, the behavior is undefined. The result need not be in the range of values of any integer type.

So integer-pointer conversions either way are implementation-defined, and pointer-to-integer conversions invoke undefined behavior if the pointer cannot be represented as an integer, which would probably be the case for an implementation with large, bound-checked pointers.

(Log in to post comments)

Remote root hole in Samba

Posted Apr 12, 2012 22:59 UTC (Thu) by khim (subscriber, #9252) [Link]

While that seems to be the intent

This was never the intent. Remember the first C standard (ANSI C 89 or ISO 90) was developed when things like iAPX 432 were supposed to be the future. Sure, this direction died off and we've got IA-32 and PPC instead, but language was defined to be usable on such architectures and in such systems. I suspect this is important for things like Alchemy today.

Remote root hole in Samba

Posted Apr 12, 2012 23:53 UTC (Thu) by nybble41 (subscriber, #55106) [Link]

There is a footnote in the C99 draft standard to the effect that the intent was for the conversions to reflect the underlying machine architecture. Not a requirement, of course--just a suggestion.

It's an application of the "principle of least surprise". On a machine with uniform, byte-addressable memory (unlike the iAPX 432), the least surprising integer representation of a pointer is the object's byte address, which can easily be converted in both directions without any loss of information.

The standard does specify that you can convert any pointer to a char* and access the object one byte at a time. I'm not sure how one would reconcile that with a type-checked architecture like the iAPX 432.