Fossil Forum

/dev/urandom", "/dev/null" is not available
Login

/dev/urandom", "/dev/null" is not available

Chronological

/dev/urandom", "/dev/null" is not available

(1) By TomaszDrozdz on 2019-07-26 13:14:33 [link] [source]

I have message:

WARNING: Device "/dev/null" is not available for reading and writing.  

WARNING: Device "/dev/urandom" is not available for reading.

Why ?

(2) By Richard Hipp (drh) on 2019-07-26 14:16:07 in reply to 1 [link] [source]

SQLite wants access to /dev/urandom in order to seed its internal PRNG. The backoffice wants to open standard input and standard output on /dev/null to prevent problems.

Neither of these are absolutely required. But they do help things to run better and more securely.

(3) By Warren Young (wyoung) on 2019-07-26 18:23:24 in reply to 1 [source]

This is usually a symptom of having run Fossil as root, in which case it enters a chroot(2) jail shortly after startup. (That's documented here.)

You can either:

  1. Use mknod(8) to provide those dev nodes inside the jail.

    (There may be other things you need to provide inside the jail as well, but since I don't do this on my own servers, I can't come up with a list off the top of my head. It should probably be a section on the above-linked doc page.)

  2. Don't run fossil server as root.

    If the reason you're doing that is so you can bind to a low-numbered TCP port, I'd recommend binding Fossil to a high-numbered static port instead. For LAN-only Fossil servers, I use 3691, being the old svnserve port number + 1. (I'm a Subversion refugee.) For Internet-facing servers, I use a semi-random port number and the --localhost flag then put an HTTPS proxy in front of it to export that to the big bad world. The above doc has some ideas for this, including a link to my complicated and powerful nginx configuration. This not only solves the "port 80" problem, it properly secures the login process, prevents MITM attacks, and more.