It is suggested in the Hardening and security guidance to give PHP read access to /dev/urandom.
Sadly, after editing php.ini within the apache2 folder accordingly, my webserver is not reachable anymore.
Even though, /dev/urandom exist on my installation.
Look out for these error messages.
So apperently you only added /dev/urandom to the open_basedir parameter. However, this parameter needs to hold every path to PHP files, which you allow to be executed. Meaning you need to add at least your nextcloud path, you NC data path and all other paths which contain data you want to access via nextcloud.
Adding your code created a couple additional errors within apache as well as nextcloud, and I added the paths, which caused the error, to open_basedir. Now I can reach Nextcloud via webserver again.
Missing arguments were /dev/fd and /proc/self/fd (seems relevant for external storage) and the paths to the nextcloud.log as well as the external storage. /var/ncdata was changed by me to the actual Nextcloud storage.
For now it seems to run without errors. Thank you very much.
Could you elaborate a little on the meanings of /dev/fd and /proc/self/fd?
Hope I really hardened the system now and didn’t mess it up.
Newer systems provide a directory named /dev/fd whose entries are files named 0,1, 2, and so on.
…
Some systems provide the pathnames /dev/stdin, /dev/stdout, and /dev/stderr. These are equivalent to /dev/fd/0, /dev/fd/1, and /dev/fd/2.
So /dev/fd is required by Nextcloud (or rather say PHP, as Nextcloud is just a PHP application which is further hardened by the open_basedir PHP parameter) to access stdin, stdout or stderr. Not sure what exactly it is needed for, but as you only opened the directories which NC required right now, you are pretty safe.
The open_basedir parameter will prevent every access to other paths you didn’t configure right now.
So yes, you rather hardened your system right now and didn’t weaken it