> On 06/25/14 21:15, Theo de Raadt wrote: > >> Here is a minor diff to do a little more strict checking on the device > >> id for urandom. It would be a shame if someone replaced a genuine > >> urandom with a /dev/null or some other predictable device. > >> > >> if a file is not special st_rdev will be 0 so S_ISCHR isn't needed anymore. > > > > So you are trying to protect against your machine being totally damaged > > already. It makes no sense at all. Those major and minor numbers do not > > make sense at all. > > > > Those numbers are what I found in urandom(4) and confirmed on Debian and > CentOS. If you can find symbolic names in the headers I would love to > add them instead of the magic numbers. > > And I'm trying to protect against the fact that if the machine has been > damaged it will not use this API to generate anything that might bite us > later on while the sys-admin could still be unaware of the problem.
That is totally ridiculous. If this device node gets screwed up, then 500 other pieces of code without the check are going to fail. > It might not be 100% foolproof, but it catches more and has about the > same performance as S_ISCHR. > > Besides, if you have the stance on you should trust /dev/urandom, > because else your system is already "totally damaged", then why put a > S_ISCHR there in the first place? For only one reason. If we didn't clone this chunk from all the other libraries which contain the same pattern, people would freak out. By the way, I think the file speaks clearly on the matter of "our stance" regarding /dev/urandom -- it is a hopelessly broken subsystem that cannot gaurantee access to random data in *all programming contexts*. (Such as file descriptor exhaustion).
