Implications of changing group to 'nobody' and setting guid bit on all files in web root

dcas

• February 04, 2016 07:16

A recent Magento security patch has introduced a problem with permissions on shared servers using SuPHP. One solution to this problem is to change the group of all files and folders in the web root to the webserver (nobody in my case) and to set the the guid bit on all directories. From a cPanel/WHM point of view, what are the implications of making the owner:group of all files in the web root account:webserver and setting the guid on all directories? [LIST]

Do any cPanel scripts expect the owner and group to be the same?

Are there any security implications in setting the group to nobody?

Will the guid flag be respected by cPanel scripts?

Is there any other reason I should not do this? Thanks

• 

  cPanelMichael

  • February 04, 2016 18:08

  Hello :) I advise against doing this if you plan to continue using suPHP because it will result in permission erorrs. Instead, have you considered DSO with Mod_Ruid2? It's documented at: Apache Module: ModRuid2 - EasyApache - cPanel Documentation Thank you.

  0
• 

  dcas

  • February 04, 2016 23:05

  Thanks for the advice @cPanelMichael, I'll take a look at ModRuid2. Could you give me an example of why using suPHP in the way I described would cause permission errors. As far as I can see, if you limit yourself to suPHP, FTP and Apache, there shouldn't be any problems. If you consider starting with a web root directory with ownership myaccount:webserver, which has permissions of 2750. [LIST]

  If you FTP into that directory as myaccount, then any file you upload will have ownership myaccount:webserver.

  If there is a PHP file in that directory with ownership myaccount:webserver, then suPHP will run it as the user myaccount.

  Running as myaccount, the PHP files will have access to all 640 files and 750 directories

  Running as myaccount, any files or directories created by the PHP script (image uploads) will have ownership myaccount:webserver

  As all file and directories have a group as webserver, then Apache will be able to read all g+r files The only way I can see problems sneaking in is if cPanel scripts aren't expecting this configuration.

  0
• 

  cPanelMichael

  • February 05, 2016 00:22

  You are welcome to utilize that custom configuration if you are comfortable with the suPHP requirements. There's a document on this at: Apache PHP Request Handling - EasyApache - cPanel Documentation Thank you.

  0
• 

  dcas

  • February 05, 2016 08:21

  Thanks for the link to the documentation, its very helpful. My concern is not whether I'm comfortable with the suPHP requirements for the proposed configuration, but whether cPanel can cope with that configuration. I'm concerned that there might be background cPanel scripts, reporting tools, configuration tools, cron tasks, deamons etc, that expect a particular owner:group and permission structure of the files in the web root. Will having not permissions for others, cause some behind the scenes jobs to fail?

  0
• 

  cPanelMichael

  • February 05, 2016 15:08

  cPanel functionality should work as expected. Your custom changes should only affect the way Apache/PHP handles the files, provided you are not modifying files outside of the public_html directory. Thank you.

  0
• 

  Valetia

  • February 07, 2016 00:09

  Do any cPanel scripts expect the owner and group to be the same?

  
  Check to see if cPanel backups still work on those files: /usr/local/cpanel/bin/backup and also perhaps: /scripts/pkgacct username I seem to recall files being owned by root within the public_html folder and its subfolders not being backed up. The same could be true for files owned by nobody.

  0

Please sign in to leave a comment.