2

The /dev/(u)random devices can be linked from the host into a container.

Can (u)random be replaced with a named pipe instead? (assuming some other application (not (u)random) provides input to the named pipe) Or does (u)random have any other functionality then being a FIFO-like device and how would such functionality be emulated without creating a new device?

Use case is having (nearly) 100% reproducible runs of applications with full control over (u)random inside a container. Having secure random numbers is of no concern.

1

A pipe wouldn't work because when several processes are reading from the same pipe, it's unpredictable which processes receives which byte. You could use a socket, however. With a socket, the server side gets a separate connection each time a client opens the socket. The server can query the process at the other end of the socket which should help predictability as you can make the PRNG seed a function of some process characteristics.

  • That link is worth gold, just as a follow up: If the runs wouldn't need to be reproducible and speed was the only concern would a pipe be enough then or is there something missing still? – birdybirb Oct 6 '16 at 21:29
  • 1
    @birdybirb With a pipe, another potential is that if there's no reader, the writer gets an end-of-file indication. But this one is solvable: in the writer, keep writing despite the EOF. – Gilles Oct 6 '16 at 21:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.