On 09/07/2016 11:08 AM, Rick Stevens wrote: > On 09/07/2016 10:26 AM, Alex wrote: >> Hi, >> >> On Tue, Sep 6, 2016 at 6:42 PM, Rick Stevens <ricks@xxxxxxxxxxxxxx> wrote: >>> On 09/06/2016 01:25 PM, Mike Wright wrote: >>>> On 09/06/2016 01:11 PM, Alex wrote: >>>>> Hi, >>>>> >>>>> I've set up a virtual host for a joomla website and having some >>>>> permissions problems. I've seen numerous configurations online about >>>>> how to set umask for the apache user, but none have worked, including >>>>> creating a systemd file >>>>> (/etc/systemd/system/multi-user.target.wants/httpd.service) with the >>>>> following: >>>> >>>>> Umask=0006 <<<<<<<< ? >>>> >>>> That comes out to 771 : rwxrwx--x. Maybe 0002 ? >> >> That still didn't work. It must not be reading that httpd.service file. >> >> -bash-4.3$ umask >> 0022 >> >>> Apache normally runs as apache:apache. Joomla is just a PHP application >>> running under Apache, so if you're using mod_php, Apache is what will >>> actually be doing the reading and writing of the files and the >>> apache:apache user should have rwx access to the entire tree. >>> >>> If you're running PHP-FPM, then the user that PHP is running as should >>> have own the tree and have rwx access to it, while Apache should have >>> at least r-x access to the tree. You could do that by putting the PHP >>> user in the apache group, giving ownership of the tree to the PHP user >>> and giving group r-x privileges: >>> >>> useradd -d /path/to/website -g apache phpuser >>> cd /path/to/website >>> chown -R phpuser:apache * >>> chmod -R 750 * >> >> The problem is then when the apache user, through the joomla admin >> front-end, needs to make changes (upload new module, etc) and the >> group doesn't have write privileges. >> >> I could sgid the directory, or write a cron script that changes all >> the permissions back as one user suggested (horrible idea), but making >> all the files and directories group-writable for user apache is a bad >> idea if the apache daemon (or joomla running as the apache user) gets >> compromised, resulting in a shell. This is the problem I'm trying to >> avoid. > > This is the inherent flaw in any application that permits self- > modification such as Joomla, FrontPage, CPanel, etc. You will have to > relax permissions at some point to permit the self-modifications and > potentially open a Pandora's box of hacks and security nightmares. > > You can obviate those by only permitting uploads to a restricted > area and having another, privileged process independently move things > to the appropriate spots periodically. > > Another option is to run the whole mess in a chrooted jail (or at least > the bits that do the self-modification). Again, going to the PHP-FPM > model, run the PHP instance in the chroot jail. If the account is > compromised, then they couldn't damage anything except the parts of > the web service inside the jail that are writable by PHP. > > Belts, suspenders, a haz-mat suit and a full-body condom are your best > defense. > ---------------------------------------------------------------------- > - Rick Stevens, Systems Engineer, AllDigital ricks@xxxxxxxxxxxxxx - > - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - > - - > - Money won't buy happiness, but it will pay the salary of a large - > - research staff to study the problem. - Bill Vaughan - > ---------------------------------------------------------------------- > -- > users mailing list > users@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe or change subscription options: > https://lists.fedoraproject.org/admin/lists/users@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines > Have a question? Ask away: http://ask.fedoraproject.org > Yep, it is a flaw in such frameworks. However most of these permission issues could be resolved if I could get apache to retain the group write privileges upon file creation, which setting apache's UMASK to 0002 would fix. So isn't that possible? I've tried all of the method I've found, including the one above, and nothing seems to make it happen. Emmett -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://lists.fedoraproject.org/admin/lists/users@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
