Subject: Re: dhcpd(8) _cannot_ be completely disabled on an interface
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
From: Andrew Brown <email@example.com>
Date: 01/08/2002 23:10:27
>I think it would be easy to make IP_RECVIF - or something similar,
>cloned from it, IP_RECVIFNAME maybe - give you the interface name
>instead of the number. Of course, it will be variable-size; this may
>complicate your userland code somewhat. Want me to try?
what about having it simply fill in (and return) a struct
sockaddr_storage? if you're game, go for it. i dont' have a use for
it at the moment...
>>>> [panic upon experimenting with routing sockets]
>>> I'm inclined to agree with you in this case. But when you're
>>> running as root, the "userland being able to panic the machine is
>>> always a bug" dictum is no longer really valid; consider
>>> dd if=/dev/zero of=/dev/mem.
>> yes, but there's a vast difference between "if i do this, i intend to
>> shoot myself in the foot" and "i will try this and expect the kernel
>> to protect my foot" expectations.
>Oh, certainly. Just remarking that I have had a great deal of trouble
>codifying that the line between "that's a bug" and "so don't do that".
sure, okay. i could argue that i was mistakenly misusing an
established interface and expecting a little protection, but i could
have gone down the same path and done the exact same thing that i
originally did with the intention of crashing the machine and gotten
what i wanted.
if you expect something of the kernel, and it doesn't live up to it
(and no, dd'ing /dev/zero into /dev/mem is *not* something you can
expect the kernel to live up to), that is, in my mind, a bug.
|-----< "CODE WARRIOR" >-----|
firstname.lastname@example.org * "ah! i see you have the internet
email@example.com (Andrew Brown) that goes *ping*!"
firstname.lastname@example.org * "information is power -- share the wealth."