Discussion:
[fossil-users] /dev/null and /dev/urandom not available ?
Olivier R.
2017-05-13 12:30:14 UTC
Permalink
Hello,

I’m running Fossil on Debian Jessie 8.2
(x86_64-debian-jessie-2016-04-06_15:26) at Scaleway.com (VC1S).

In the admin panel, Fossil says:

WARNING: Device "/dev/null" is not available for reading and writing.
WARNING: Device "/dev/urandom" is not available for reading. This
means that the pseudo-random number generator used by SQLite will be
poorly seeded.

fossil is in usr/bin.
repo.fossil is in /root/repo.

To launch the server, I simply type:

fossil open repo.fossil
nohup fossil server &

In /dev, there is:

crw-rw-rw- 1 root root 1, 3 Apr 8 2016 null
crw-rw-rw- 1 root root 1, 9 Apr 8 2016 urandom


If I clone the repository, modify something, commit the modification,
fossil says when trying to sync:

Autosync: http://xxx.xxx.xxx.xxx:8080
Round-trips: 1 Artifacts sent: 0 received: 0
Pull done, sent: 312 received: 328 ip: xxx.xxx.xxx.xxx
New_Version: xxxxxxxxxxxxxxxxxxxx_hash_code_xxxxxxxxxxxxxxxxxxxxx
Autosync: http://xxx.xxx.xxx.xxx:8080
Round-trips: 1 Artifacts sent: 2 received: 0
Error: not authorized to write
Round-trips: 1 Artifacts sent: 2 received: 0
Sync done, sent: 759 received: 355 ip: xxx.xxx.xxx.xxx
Autosync failed.

The repository has not been updated.

How to solve these problems?

Olivier
Richard Hipp
2017-05-13 12:50:03 UTC
Permalink
Post by Olivier R.
Hello,
I’m running Fossil on Debian Jessie 8.2
(x86_64-debian-jessie-2016-04-06_15:26) at Scaleway.com (VC1S).
WARNING: Device "/dev/null" is not available for reading and writing.
WARNING: Device "/dev/urandom" is not available for reading. This
means that the pseudo-random number generator used by SQLite will be
poorly seeded.
fossil is in usr/bin.
repo.fossil is in /root/repo.
fossil open repo.fossil
nohup fossil server &
Are you running the commands above as root? If so, Fossil will
automatically put itself in a chroot jail on the directory containing
the repository and drop root privileges before doing anything else.
This is a security feature.

If you are going into a chroot jail, probably /dev/null and
/dev/urandom are no longer in that chroot jail. You can fix that by
running:

mkdir dev
mknod dev/null c 1 3
mknod dev/urandom c 1 9

See also the "managing server load" heading of
http://fossil-scm.org/fossil/doc/trunk/www/server.wiki where it talks
about the importance of making /proc available inside the chroot jail
so that Fossil can determine the load average.

Or, you can use the --nojail option on the "fossil server" command, in
which case Fossil will still drop its root privilege but will not
attempt to form a chroot jail. This is less secure, but probably
still plenty safe.
Post by Olivier R.
crw-rw-rw- 1 root root 1, 3 Apr 8 2016 null
crw-rw-rw- 1 root root 1, 9 Apr 8 2016 urandom
If I clone the repository, modify something, commit the modification,
Autosync: http://xxx.xxx.xxx.xxx:8080
Round-trips: 1 Artifacts sent: 0 received: 0
Pull done, sent: 312 received: 328 ip: xxx.xxx.xxx.xxx
New_Version: xxxxxxxxxxxxxxxxxxxx_hash_code_xxxxxxxxxxxxxxxxxxxxx
Autosync: http://xxx.xxx.xxx.xxx:8080
Round-trips: 1 Artifacts sent: 2 received: 0
Error: not authorized to write
Round-trips: 1 Artifacts sent: 2 received: 0
Sync done, sent: 759 received: 355 ip: xxx.xxx.xxx.xxx
Autosync failed.
The repository has not been updated.
How to solve these problems?
Olivier
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
--
D. Richard Hipp
***@sqlite.org
Olivier R.
2017-05-13 17:06:53 UTC
Permalink
Thanks.

Olivier
Post by Richard Hipp
Are you running the commands above as root? If so, Fossil will
automatically put itself in a chroot jail on the directory containing
the repository and drop root privileges before doing anything else.
This is a security feature.
If you are going into a chroot jail, probably /dev/null and
/dev/urandom are no longer in that chroot jail. You can fix that by
mkdir dev
mknod dev/null c 1 3
mknod dev/urandom c 1 9
See also the "managing server load" heading of
http://fossil-scm.org/fossil/doc/trunk/www/server.wiki where it talks
about the importance of making /proc available inside the chroot jail
so that Fossil can determine the load average.
Or, you can use the --nojail option on the "fossil server" command, in
which case Fossil will still drop its root privilege but will not
attempt to form a chroot jail. This is less secure, but probably
still plenty safe.
Roy Keene
2017-05-15 14:15:02 UTC
Permalink
Maybe it should open /dev/null and /dev/urandom before chroot()'ing ?
Post by Richard Hipp
Post by Olivier R.
Hello,
I?m running Fossil on Debian Jessie 8.2
(x86_64-debian-jessie-2016-04-06_15:26) at Scaleway.com (VC1S).
WARNING: Device "/dev/null" is not available for reading and writing.
WARNING: Device "/dev/urandom" is not available for reading. This
means that the pseudo-random number generator used by SQLite will be
poorly seeded.
fossil is in usr/bin.
repo.fossil is in /root/repo.
fossil open repo.fossil
nohup fossil server &
Are you running the commands above as root? If so, Fossil will
automatically put itself in a chroot jail on the directory containing
the repository and drop root privileges before doing anything else.
This is a security feature.
If you are going into a chroot jail, probably /dev/null and
/dev/urandom are no longer in that chroot jail. You can fix that by
mkdir dev
mknod dev/null c 1 3
mknod dev/urandom c 1 9
See also the "managing server load" heading of
http://fossil-scm.org/fossil/doc/trunk/www/server.wiki where it talks
about the importance of making /proc available inside the chroot jail
so that Fossil can determine the load average.
Or, you can use the --nojail option on the "fossil server" command, in
which case Fossil will still drop its root privilege but will not
attempt to form a chroot jail. This is less secure, but probably
still plenty safe.
Post by Olivier R.
crw-rw-rw- 1 root root 1, 3 Apr 8 2016 null
crw-rw-rw- 1 root root 1, 9 Apr 8 2016 urandom
If I clone the repository, modify something, commit the modification,
Autosync: http://xxx.xxx.xxx.xxx:8080
Round-trips: 1 Artifacts sent: 0 received: 0
Pull done, sent: 312 received: 328 ip: xxx.xxx.xxx.xxx
New_Version: xxxxxxxxxxxxxxxxxxxx_hash_code_xxxxxxxxxxxxxxxxxxxxx
Autosync: http://xxx.xxx.xxx.xxx:8080
Round-trips: 1 Artifacts sent: 2 received: 0
Error: not authorized to write
Round-trips: 1 Artifacts sent: 2 received: 0
Sync done, sent: 759 received: 355 ip: xxx.xxx.xxx.xxx
Autosync failed.
The repository has not been updated.
How to solve these problems?
Olivier
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
--
D. Richard Hipp
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Joerg Sonnenberger
2017-05-15 17:06:11 UTC
Permalink
Post by Roy Keene
Maybe it should open /dev/null and /dev/urandom before chroot()'ing ?
At /dev/urandom doesn't need to be used on newer Linux systems,
getentropy/getrandom provide the same service as system call.

Joerg
Richard Hipp
2017-05-15 17:13:18 UTC
Permalink
Post by Roy Keene
Maybe it should open /dev/null and /dev/urandom before chroot()'ing ?
That would be difficult to implement.
--
D. Richard Hipp
***@sqlite.org
Warren Young
2017-05-15 19:25:30 UTC
Permalink
Post by Richard Hipp
Are you running the commands above as root?
…and if so, I would guess the only reason you’re running it as root is so that it can listen on port 80, in which case I *strongly* encourage you to bind Fossil to localhost on a high-numbered random port and put a proxy in front of it, ideally configured for TLS.

That way, not only do you fix the /dev access problems, you bypass or wall off a whole pile of security problems.

I wrote up a guide to do that [1] about a year ago, at which time Let’s Encrypt on nginx required manual certificate updating. I should probably rewrite that guide now that the automatic update stuff is sorted out in certbot.

The bulk of that guide won’t be substantially different, though, so if you can work out the differences on your own, it’ll probably still be helpful to you as-is.


[1]: https://www.mail-archive.com/fossil-***@lists.fossil-scm.org/msg22907.html
Ross Berteig
2017-05-15 20:42:01 UTC
Permalink
Post by Richard Hipp
Post by Olivier R.
....
fossil open repo.fossil
nohup fossil server &
Are you running the commands above as root? If so, Fossil will
automatically put itself in a chroot jail on the directory containing
the repository and drop root privileges before doing anything else.
This is a security feature.
If you are going into a chroot jail, probably /dev/null and
/dev/urandom are no longer in that chroot jail. You can fix that by
mkdir dev
mknod dev/null c 1 3
mknod dev/urandom c 1 9
....
You will also probably want to put the local timezone file inside the
jail, so that the server can display the timeline in server local time
instead of UTC if you choose. Without that, the option "Use UTC" in
/setup_timeline will have no effect. That puzzled me for a while when I
first stood up a fossil on Ubuntu because there are no error messages
anywhere when there is no timezone. Processes just see local time and
UTC time as equivalent, silently.

In that installation I'm using inetd to do the listening on a port other
than 80 and launching fossil as needed. But it is launched as root, so
it lands in a chroot jail. The jail is rooted at the folder containing
the .fossil file (or folder of .fossil files) being served, so along
with *.fossil I have dev/urandom, dev/null, and etc/localtime (which is
a copy and not a symbolic link because the chroot jail won't allow the
link to be followed).
--
Ross Berteig ***@CheshireEng.com
Cheshire Engineering Corp. http://www.CheshireEng.com/
+1 626 303 1602
Loading...