With the prosody 0.9.9 update, prosody tries to open /dev/urandom as r+ (instead of just r) in util/uuid.lua (see [1]). This causes a crash if prosody isn't running as root and constitutes quite a disruptive change for a small, stable update. Furthermore, the ability to write to /dev/urandom is never really used inside the code, except for the seed function in the same file, which as far as I can tell is never getting called anywhere else in the code. Since urandom usually doesn't require seeding[2] to generate secure random values, the functionality in itself seems superfluous and should probably be removed or at least be made optional. [1] https://hg.prosody.im/trunk/file/c633e1338554/util/uuid.lua#l11 [2] except at system start, which is usually handled by the startup script.

Hi, thanks for the report! Can you provide details about your system?

• owner MattJ

Oh jeez, I just realized that this might actually be a bug in the openvz setup in which prosody is running, as urandom is actually 666 (I've assumed 644 without looking it up), but writing to urandom is not permitted in the container. The system in question is a Debian 6.0.10 (yes, old :/), prosody (as well as most of the required libraries) is installed via the http://packages.prosody.im/debian squeeze main repository. For completeness, here's the error message that is generated at startup: Starting Prosody XMPP Server: prosody/usr/bin/lua5.1: /usr/lib/prosody/util/uuid.lua:27: Unable to obtain a secure random number generator, please see https://prosody.im/doc/random (/dev/urandom: Operation not permitted) stack traceback: [C]: in function 'error' /usr/lib/prosody/util/uuid.lua:27: in function 'uuid_gen' /usr/lib/prosody/core/hostmanager.lua:77: in function 'activate' /usr/lib/prosody/core/hostmanager.lua:44: in function '?' /usr/lib/prosody/util/events.lua:67: in function 'fire_event' /usr/bin/prosody:337: in function 'prepare_to_start' /usr/bin/prosody:403: in main chunk [C]: ? I suppose this issue could be closed, as it is strictly speaking not a prosody error, but rather a problem in the setup that doesn't permit write access to urandom. Sorry for the noise. :/ (Just a remark: Is urandom opened before or after root privileges are dropped? If urandom is opened as the user, then this might still fail on systems such as OpenBSD, where urandom is 644. Maybe such a failure should be handled more... gracefully?)

Thanks for the further information, it's helpful :) I'm going to leave the issue open for a bit, while we decide what and whether we'll do about it. You aren't the first person to have problems with urandom permissions today (though the other was seemingly unrelated, and due to a custom AppArmor profile). So it's not totally broken, but if a few people are having trouble with it then it's worth reviewing. We tried our best to test on different systems, but obviously can never catch everything. Regarding dropping root... Prosody itself never runs as root. We do have root-dropping code in prosodyctl, as that's sometimes run as root for convenience, but it just switches to the prosody user before launching the daemon. We decided to keep it this way and cut out a whole category of potential security issues.

I too have a custom AppArmor profile and see no good reason to grant prosody write access to urandom; the <abstractions/base> profile grants only read access to [u]random. Please don't require more permission on the system than you actually need. Also this is kinda bad in a security update.

Hi Stefan, thanks for the comment. I'm sorry you've been affected by this issue also. Firstly let me clarify that under Linux writing to urandom is a harmless operation (see man urandom), and on all the systems we tested before the release it worked fine. And the majority of users have indeed had no problem with it. Our switch to using urandom was considered the best of a number of options, e.g. as it did not add any extra dependencies (which would also be kinda bad in a security update). We tried to make the best choice we could in the circumstances. Writing to urandom came as an attempt to preserve the existing semantics of the code as much as possible, which already had a seed() function to feed data into the random number generator. In hindsight this could have become a no-op during the switch to urandom (i.e. we would always assume urandom is well-fed) if we had known it would cause issues for some people, but obviously we weren't blessed with hindsight at the time. We're going to remove the requirement for write access in the next minor update.

• tag Status-Fixed

Hi guys, I wanted to give prosody a try, but I'm running into the same error on Ubuntu 14.04. When can we expect the next minor update? Thx for your work!

The next release will be in the coming week, very soon. Anyone who posts here and is affected by the issue, I'm still curious to hear what kind of environment you folk are running Prosody under (we still don't have a very clear picture of who exactly is affected). I think most of the issues have come down to AppArmor and some virtualization systems so far. And possibly some flavours of BSD.

Hey, yes I'm running Ubuntu 14.04 on a VPS (virtualization system: Linux-VServer). I remember having a problem with another program due to a denied access on the random number generator because of the virtualization. So I guess in my case virtualization causes the error.

SELinux prevents Prosody from writing to /dev/urandom; I just remembered to https://bugzilla.redhat.com/show_bug.cgi?id=1076979 where I had exactly the same issue with Heimdal last year. SELinux covers all Fedora and RHEL/CentOS releases by default. I already backported the patch from the nightly builds into the RPM about 14+ days ago to satisfy Fedora user complaints.

Just released the fix for this issue in 0.9.10. Enjoy!

• tags Milestone-0.9