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.

birdybirb
  • 23

1 Answers1

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.

Community
  • 1
Gilles 'SO- stop being evil'
  • 829,060
  • 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 06 '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 'SO- stop being evil' Oct 06 '16 at 21:37