Per customer request we needed to configure one of Virtualmin servers to create virtual servers in "Apache mod_php (run as Apache's user)" mode instead of default "FCGId (run as domain owner)", however we are seeing two major issues:
(1) Even if Virtualmin is configured to create virtual servers in "Apache mod_php (run as Apache's user)" mode, all the files and directories in document root belong to the website username group like username:username, whereas we expected them to be created with the following ownership:
username:apache (on RHEL/CentOS)
(2) After running "chgrp -R apache /home/username/public_html" validating the virtual server gives:
username.com
Home directory : Sub-directory public_html under home directory is owned by group apache instead of username
How can we properly set Virtualmin so that all the files and directories belong to Apache group and Virtualmin validation not to complain about it?
Comments
Submitted by andreychek on Tue, 05/12/2015 - 09:58 Comment #1
Howdy -- unfortunately, that's one of the issues with using mod_php. It's a bit more difficult to get the permissions setup.
Files and directories that require write permissions usually need to be setup manually to allow that.
Also, if it's a multi-user system, setting public_html to be owned by the group "apache" would allow all other web users on the server to modify the files in your DocumentRoot
Knowing all that, if you really want all files and directories created under the public_html file to be owned by the group apache, you could always make the directories set group id "apache".
That is, if you run "chgrp g+s /home/username/public_html", any new files or directories created in public_html would be created with the group being apache, and not the Virtual Server owner.
Submitted by yngens on Tue, 05/12/2015 - 18:17 Comment #2
To say frankly I am totally dissatisfied with your reply. You just repeated what I had already reported. We know how to attribute all the files and directories to apache group, however to reinstate:
(1) We need Virtualmin to do so automatically. There should be some way as we rely on Virtualmin exactly because we want to minimize manual work.
(2) We need Virtualmin's validation script to be happy about files and directories belonging to Apache grouup in case if mod_php mode is used.
And we really hope Jamie will come up with some viable solution as there are too many this kind of unresolved issues with Virtualmin. After number of years of using Virtualmin we really do not want to convert to Virtualizor, which doesn't have this kind of limitations. If it has their developers address them shortly not leaving everything in "unfortunate" state.
Submitted by JamieCameron on Tue, 05/12/2015 - 21:06 Comment #3
One simpler option would be to give the public_html directory and all other files and dirs that you want Apache to be able to write to group-write permissions. Because the
apache
user is in all domains' groups, this will ensure that write access works without needing to change file ownership.Submitted by yngens on Fri, 05/15/2015 - 07:05 Comment #4
Well, then Security Review module for Drupal (https://www.drupal.org/project/security_review)won't be happy. One of the reasons why we are trying to switch to mod_php is because FCGId will not pass Security Review check. Now we are in state when none of FCGId or mod_php is passing through, which is quite sad.
Submitted by yngens on Fri, 05/15/2015 - 19:32 Comment #5
Hi Jamie,
Any updates on this?
If we could take care of the problem #1
(1) We need Virtualmin to do so automatically. There should be some way as we rely on Virtualmin exactly because we want to minimize manual work.
by scripting, the problem #2:
(2) We need Virtualmin's validation script to be happy about files and directories belonging to Apache grouup in case if mod_php mode is used.
should really by addressed by Virtualmin as there is no point for validation script to complain about group ownership if a virtual server is running in Apache mod_php.
Submitted by JamieCameron on Fri, 05/15/2015 - 22:34 Comment #6
Actually, if you install Drupal via Virtualmin in mod_php mode, it should already make the required directories that Drupal uses for uploads writable. Which specific directories are you having trouble with?
Submitted by yngens on Sat, 05/16/2015 - 18:16 Comment #7
Jamie,
Please just sit once on this issue and read carefully what I am trying to report. The validation page complains not about particular file or directory, but the whole home directory if it belongs to group "apache":
Home directory : Sub-directory public_html under home directory is owned by group apache instead of bomba
We need Drupal websites installed on our Virtualmin websites to somehow pass Security Review module's checks (https://www.drupal.org/project/security_review) and the only way to pass it to attribute all the files and directories to different user and group. And for some reason that is not possible in FCGId mode, but possible in Apache mod_php, however in this case Validation is complaining about the fact the files and directories belong to "apache" group.
Why Virtualmin is made so that all files and directories MUST belong to the same user and group? Why can't they belong to a group different that a user?
This has already been discussed on http://virtualmin.com/node/35011 and unfortunately nothing has been done in this respect since then.
Please understand that we are trying to give best of both Drupal and Virtualmin, but this issue is where two software do not meet each other. Please show me any way for Virtualmin website to pass through Security Review check's and I'll be satisfied and be done with coming up with this issue again and again.
Unfortunately, af Virtualmin can not ever pass Security Review module's checks then we have no other choice, but walking away from Virtualmin.
Submitted by JamieCameron on Sat, 05/16/2015 - 18:40 Comment #8
So, I will change Virtualmin in the next release to not fail domain validation if the
public_html
directory is owned by the Apache user. Virtualmin's existing support for running custom code after creation of a domain or installation of a script could then be used to set whatever permissions you want - once done, your users wouldn't have to perform any additional steps when installing scripts.Submitted by yngens on Sun, 05/17/2015 - 12:42 Comment #9
That would be great, Jamie. Thank you for listening and understanding!