On 09/07/2016 03:19 PM, Rick Stevens wrote: > On 09/07/2016 01:38 PM, Emmett Culley wrote: >> 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. >>> >> 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. > > I know you've futzed with the systemd things, but did you modify the > /usr/lib/systemd/system/httpd.service file (which is the target of the > symlink "/etc/systemd/system/multi-user.target.wants/httpd.service") > and modified the two lines that read: > > ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND > ExecReload=/usr/sbin/httpd $OPTIONS -k graceful > > to read: > > ExecStart=umask 002;/usr/sbin/httpd $OPTIONS -DFOREGROUND > ExecReload=umask 002;/usr/sbin/httpd $OPTIONS -k graceful > > (insert "umask 002;" between the "=" and the command). Just stuffing > "umask 002" into the file itself will change it for the systemd script, > but not necessarily the subshells that are forked to actually spawn the > apache process (not 100% sure of that...not sure how systemd forks > things). Note that running "umask" in a separate shell will tell you > the umask of the shell you ran "umask" in...not the one running Apache. > > In ye olde days you could edit the "/etc/login.defs" file and put in a > line that read: > > QUOTAS_ENAB yes > > Then you had to modify the /etc/passwd entry for the apache user and put > "K002" in the GECOS field, e.g. > > Old: > apache:x:48:48:Apache:/usr/share/httpd:/sbin/nologin > > New: > apache:x:48:48:Apache K002:/usr/share/httpd:/sbin/nologin > > This may not work as it typically only affects processes that have been > spawned by login and only if login pays attention to the GECOS key > fields. > ---------------------------------------------------------------------- > - Rick Stevens, Systems Engineer, AllDigital ricks@xxxxxxxxxxxxxx - That didn't help either: Sep 07 14:19:51 horse-magazine.info systemd[1]: Reloaded The Apache HTTP Server. Sep 07 16:35:47 horse-magazine.info systemd[1]: [/usr/lib/systemd/system/httpd.service:10] Executable path is not absolute, ignoring: umask 002;/usr/sbin/httpd $OPTIONS -DFOREGROUND Sep 07 16:35:47 horse-magazine.info systemd[1]: [/usr/lib/systemd/system/httpd.service:11] Executable path is not absolute, ignoring: umask 002;/usr/sbin/httpd $OPTIONS -k graceful Sep 07 16:35:47 horse-magazine.info systemd[1]: [/usr/lib/systemd/system/httpd.service:20] Unknown lvalue 'umask' in section 'Service' Sep 07 16:35:47 horse-magazine.info systemd[1]: httpd.service has no ExecStart= setting, which is only allowed for Type=oneshot services. Refusing. 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
