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:
>>> On Tue, Sep 6, 2016 at 6:42 PM, Rick Stevens <ricks(a)alldigital.com>
>>>> On 09/06/2016 01:25 PM, Mike Wright wrote:
>>>>> On 09/06/2016 01:11 PM, Alex wrote:
>>>>>> I've set up a virtual host for a joomla website and having
>>>>>> permissions problems. I've seen numerous configurations
>>>>>> how to set umask for the apache user, but none have worked,
>>>>>> creating a systemd file
>>>>>> (/etc/systemd/system/multi-user.target.wants/httpd.service) with
>>>>>> 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
>>>> 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
>>>> 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
>>>> 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
>> 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
> 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
and modified the two lines that read:
ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND
ExecReload=/usr/sbin/httpd $OPTIONS -k graceful
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:
Then you had to modify the /etc/passwd entry for the apache user and put
"K002" in the GECOS field, e.g.
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
- Rick Stevens, Systems Engineer, AllDigital ricks(a)alldigital.com -
That didn't help either:
Sep 07 14:19:51 horse-magazine.info systemd: Reloaded The Apache HTTP Server.
Sep 07 16:35:47 horse-magazine.info systemd: [/usr/lib/systemd/system/httpd.service:10]
Executable path is not absolute, ignoring: umask 002;/usr/sbin/httpd $OPTIONS
Sep 07 16:35:47 horse-magazine.info systemd: [/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: [/usr/lib/systemd/system/httpd.service:20]
Unknown lvalue 'umask' in section 'Service'
Sep 07 16:35:47 horse-magazine.info systemd: httpd.service has no ExecStart= setting,
which is only allowed for Type=oneshot services. Refusing.