Yes:

   EPERM  mode requested creation of something other than a regular
              file, FIFO (named pipe), or UNIX domain socket, and the caller
              is not privileged (Linux: does not have the CAP_MKNOD
              capability); also returned if the filesystem containing
              pathname does not support the type of node requested.

Of course there is still the theoretical problem that you could be running in a chroot where some unprivileged user has write access to the root and/or /dev so that she can create symlinks or move files around there. I don't think that should be the responsibility of the library to defend against though; but the responsibility of whoever created that chroot dir...

I agree, but it's really theoretical: If the user has write access to the chroot environment, she can just replace the binary or play tricks with the libraries. No way the (then not even run) binary can defend against that. Didn't try it, but I would guess that subverting crypto is /slightly/ easier if you can run your own code instead of just manipulating the random seeds.

No kidding.

Talk about looking for problems that don't exist!

I guess that mentality is good in a crypto developer, but he took it to unnecessary extremes.

One or both of us is confused.

EDIT I was confused.

I think the OP is right. The first mistake he mentions is just not reading enough from urandom and thus falling back on unsecure values, which is just sloppy C. Then all the other attack scenarios require the ability to replace /dev/urandom in various insane ways (sparse actual files, symlinks, other devices). It all just seems pretty pointless. Just read /dev/urandom in a loop until you have enough and abort on any other case. That way you assure a secure result as long as the user has a sane environment and abort otherwise.