Hello, I have ispconfig 3.2.7p1 with apache webserver. i am installing mediawiki. for security wiki team recommends : " File permissions Another very important thing you should do to secure your MediaWiki installation: Make sure the user running php does not have write access to any web-accessible file or directory that php is enabled to run on. On Debian-based systems this means the www-data user should not own the php files. " It is not clear to me who is running php with ispconfig : is it www-data or is it webx ? Thank you for your help and recommendations on that topic.
PHP is run as a different user and group for each website. Setting for permissions so the PHP user can't write to them seems difficult on an ispconfig system, unless I'm overlooking something obvious; is this for a client site, or one you as the server admin operate? My current top idea would be to create a second site under which you create your shell (or FTP?) use that is used to manage the actual website files; ensure group read permission, and execute for directories, but not write. Then use bind mount to mount the actual website files over the original website's /web root. In your bind mount options you can remap the group ID (but not the user ID) from the second site to the first. Then PHP should be able to access the files via the group permissions, but not write to them. Another option would be skip the bind mount and just have 2 websites, one for the actual web, the other to create a shell user to manage the site files, then as root, create a cron job that copies the site files over to the actual website, and sets file ownership/permissions so that PHP dies not have write access
On an Apache server, you could e.g. uncheck the suexec checkbox in the website settings, this will make PHP run as www-data user instead of the web user, and as all files in the website are owned by the website user, the user that runs PHP (www-data) has no write permissions anymore.
This is true if you are using fast-cgi mode, but not with php-fpm which always runs as the website user id (is that a bug?); but even with fast-cgi mode, if other clients are able to disable suexec on their own sites, they will have more or less the same access to your mediawiki as the actual website has, which might be bad (or not, depending on your environment). Strict php configuration (like disable_functions and open_basedir) can help there, but realistically there are almost always ways to work around those restrictions as modern sites often won't function correctly without relaxing some of those. But indeed, if you only need to achieve files being unwritable by the php process user on a relatively purpose-built, this is much simpler.
I am with php-fpm... And as I can see mediawiki uses bash script... so probably exec function ! As you suggest, I will chmod -w to remove write access to php-fpm user. If I need write access, I'll revert with chmod +w access... Thanks a lot for sharing your expertise
In your setup you might consider php-fpm in chroot mode (you may well need to add things to your chroot environment, depending on what dolibarr needs), and if this server has other sites consider setting up an additional php version just for the dolibarr site which allows exec() or whatever is used, if your policy otherwise is to disable it; then at least all the other sites aren't made less secure because the dolibarr site needs that config.
I though that php-fpm worked by site... and I can allow exec() per site in the php.ini of ispconfig website snippet I am very worried by what you says. Moreover, mediawiki bash scripts start by #!/bin/bash So that I should include /bin in open_basedir... You say "chrooted"
