[jjnoakes]

It fails in a poorly set up chroot, not any old chroot.

It also fails in a poorly set up root file system in the same way. No chroot needed.

I can't remember ever running out of file descriptors unless a program had a leak. But if you want to argue that position too, make sure you mention that cputime and memory could also be exhausted, leading to... well... any other method failing in a similar fashion.

A system call definitely has some minor benefits over a file in /dev, bit the reverse is also true (access from shells, or any language really, with no built in support).

But calling /dev/urandom unreliable is a little bit intellectually dishonest.

[neerdowell]

> It fails in a poorly set up chroot, not any old chroot.

It fails for any program that calls chroot(2) and chroots to a location that hasn't had /dev/urandom constructed, which is... almost every program that sandboxes by calling chroot(2).

> I can't remember ever running out of file descriptors unless a program had a leak.

You've probably never used ulimits or login groups then.

> But if you want to argue that position too, make sure you mention that cputime and memory could also be exhausted, leading to... well... any other method failing in a similar fashion.

You're writing a library and in one of the functions you call arc4random(3). How would you handle memory being exhausted at the time when arc4random is called? Hint: you wouldn't. You'd let the OS handle it, probably by terminating something. Which might be the running process or another process.

New situation, you're writing a library and in one of the functions you open() a file handle and read() from it. How would you handle that operation failing? Thought about it? Got your answer? Good.

Now see the comments in LibreSSL for why your answer to that is wrong: https://github.com/libressl-portable/openbsd/blob/cb62fd8b9b...

> But calling /dev/urandom unreliable is a little bit intellectually dishonest.

/dev/urandom is not a high-availability randomness source, therefore it is unreliable. It is not intellectually dishonest, it is a statement of fact.

[jjnoakes]

> It fails for any program that calls chroot(2) and chroots to a location that hasn't had /dev/urandom constructed, which is... almost every program that sandboxes by calling chroot(2).

Yeah. Those programs fail if they try to do anything with the file system they weren't set up for. Running external commands via the shell? Better have /bin/sh. Running executables? Better have the libraries set up. Resolving hostnames? Better have the files in /etc and nsswitch and others. Probably want a /dev/tty. /dev/null. /proc mounted. /sys mounted. Or, if you are really a super bare bones app which knows it doesn't need any of that stuff, you pre-read /dev/urandom before you chroot(2) or you use the system call.

None of that means /dev/urandom is unreliable.

> You've probably never used ulimits or login groups then.

Sure I have. But I have never run anything that needed more than 32 open files at a time. If your limits are pathologically low, you can come up with any scenario where trivial programs fail to work. But such a discussion isn't productive.

> [bunch of nonsense]

Returning an error code seems to be a fine option if your library is asked to perform a task and it can not. I see nothing in LibreSSL which indicates that this is a bad idea.

What IS a bad idea is falling back to some nonsense like getuid() + getpid() + time() instead of returning some error. If you can't access a random number generator and you need a random number (and especially if you are a cryptography library) then return a failure error code.

But that's orthogonal to this discussion (why did you bring up LibreSSL?)

> /dev/urandom is not a high-availability randomness source

Well by your definition, nothing is high-availability, so everything is unreliable. So I guess you are right, in your world, but your argument just became meaningless.

A system call is better, but /dev/urandom is fine.