Re: sin_zero

[Motoyuki OHMORI <ohmori%chikushi-u.ac.jp@localhost>]

Hi, 

> What I'm wondering is, would this break anything?  It seems to me like
> a no-downside change, but there's a lot of code I don't truly
> understand running around there.  I'm of the opinion that the most
> correct thing to do is to change it and then fix anything it breaks,
> because that really is the correct configuration.  But for the purposes
> at hand here, I'd rather work around the bug in userland than get
> involved in debugging of long-standing and widely scattered kernel
> issues exposed by such a change.  I could, of course, just change it
> and see, but there may be issues like "that would expose random kernel
> memory to nonprivileged userland via $THING" which aren't obviously
> broken but are clearly undesirable.

From theoretical point of view, I agree with you.  However, From the practital,
I am wondering whether your modification may break existing routing daemons
such as routed, gated, mrt, zebra (quagga), xorp and so on because they listen
on a routing socket to import kernel routes into them.  At a glance, routed
seems to be okay but others are unknown.

BTW, even with your modification, you may still need to properly set sin_len to
not sizeof(struct sockaddr_in) but like offsetof(struct sockaddr_in, sin_zero)
in order to make kernel ignore uninitialized sin_zero.  I am afraid that this
would make it difficult to write a portable code because all OSes do not have
non-standard sin_zero field.  Just initializing struct sockaddr_in with all
zeros is very portabale, IMHO.

Best regards,
--
Motoyuki OHMORI <ohmori%chikushi-u.ac.jp@localhost>