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:
[Unit] Description=The Apache HTTP Server After=network.target remote-fs.target nss-lookup.target
[Service] Type=notify Environment=LANG=C Umask=0006
ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND ExecReload=/usr/sbin/httpd $OPTIONS -k graceful # Send SIGWINCH for graceful stop KillSignal=SIGWINCH KillMode=mixed PrivateTmp=true
[Install] WantedBy=multi-user.target
The problem is that the files are owned by the joomla user, but also need to have access (both read and write) to be able to modify some files within the document root.
Does anyone have any suggestions on how to set umask for the apache user?
I'm also interested in recommended permissions settings for the joomla document root.
Thanks, Alex
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 ?
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 ?
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 *
or something like that. Also watch out for selinux denials. "Here be dragons!" ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - Hard work has a future payoff. Laziness pays off now. - ----------------------------------------------------------------------
Hi,
On Tue, Sep 6, 2016 at 6:42 PM, Rick Stevens ricks@alldigital.com 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.
Thanks, Alex
On 09/07/2016 10:26 AM, Alex wrote:
Hi,
On Tue, Sep 6, 2016 at 6:42 PM, Rick Stevens ricks@alldigital.com 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@alldigital.com - - 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 - ----------------------------------------------------------------------
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@alldigital.com 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@alldigital.com -
- 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@lists.fedoraproject.org To unsubscribe or change subscription options: https://lists.fedoraproject.org/admin/lists/users@lists.fedoraproject.org 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
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@alldigital.com 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@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - To err is human, to moo bovine. - ----------------------------------------------------------------------
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@alldigital.com 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@alldigital.com -
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
On 09/07/2016 03:19 PM, Rick Stevens wrote:
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 On 09/07/2016 03:19 PM, Rick Stevens wrote:
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
I finally figured out how to get the umask set for apache. Well actually php-fpm.
In /usr/lib/systemd/system/php-fpm.server, add the line:
UMask=002
under the [Service] section. If you have other PHP versions running, like vis remi, yu may want to add that line for those php-fpm.service files. Like /usr/lib/systemd/system/php74-php-fpm.server for any site that requires PHP 7.4. Though it is mostly Laravel sites where we need a specific PHP version, at least temporarily.
Now all files and directories created by my web server have group write set. This supports wordpress sites as I enable local FTP for plugins and wordpress to use for updates, and I set all directories to g+ws and set the group to the FTP user. In my case I create a system user for each wordpress site, then cause proftp to allow local FTP access to their home directory, which is sym linked to the wordpress site's root.
So wordpress automaticaly has the ability to write all files in the root directory. I suppose we have to trust that wordpress will not write hacked files to the server's root. So it behoovs our site webmasters to not unstall untrusted plugins. At least, using local ftp prevents any access outside that site's web root.
Emmett
On Tue, 2022-08-02 at 15:22 +0000, Emmett Culley via users wrote:
So wordpress automaticaly has the ability to write all files in the root directory. I suppose we have to trust that wordpress will not write hacked files to the server's root.
You are aware that it has a bad reputation for security? You'll need to keep on top of it being updated all the time. It's a prime target.
So it behoovs our site webmasters to not unstall untrusted plugins.
This is where you need one or two competent and trustworthy webmasters. General page authors aren't webmasters.
On 8/2/22 8:47 PM, Tim via users wrote:
On Tue, 2022-08-02 at 15:22 +0000, Emmett Culley via users wrote:
So wordpress automaticaly has the ability to write all files in the root directory. I suppose we have to trust that wordpress will not write hacked files to the server's root.
You are aware that it has a bad reputation for security? You'll need to keep on top of it being updated all the time. It's a prime target.
So it behoovs our site webmasters to not unstall untrusted plugins.
This is where you need one or two competent and trustworthy webmasters. General page authors aren't webmasters.
Thanks for your comments.
All true. And there is nothing to do but grin and bear it, as many of our clients want to use wordpress. We keep a watch for "bad" files, and we also survey what plugins are installed and when a new one shows up one of us researches it. We have found a couple of bad actors, but if a webmaster sticks to wordpress approved plugins, we see no issues our current methods cannot mitigate.
Right now we are dealing with DIVI booster issues. It wants write access to wp-content anytime you edit the site. I've contected them, but so for no response. In the mean time I have to temporarily enable apache write access to wp-content, then reinstect the site' files after disableing that access. If is isn't fixed by DIVI booster soon I will require that the client uninstall that theme plugin. They won't be happy, but they will like that better than getting a bill every tiem they need to edit their site.
I am considering changing the name of the wp-content directory, but obfuscation only gives false confidence as hack mitigation. Besides, that would require hands of from our engineers for each wordpress site.
Emmett
Hi,
On Tue, Sep 6, 2016 at 6:42 PM, Rick Stevens ricks@alldigital.com 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 ?
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 *or something like that. Also watch out for selinux denials. "Here be dragons!"
Some time ago, I had posted a message to this list regarding apache permissions in a DocumentRoot with joomla. The problem I was having was with the user doing local modifications (joomadmin) not being able to modify files uploaded or changed by the joomla apache user (apache).
Numerous suggestions were made, including changing all the files to be sgid write, adding the users to a common group, and other, more complicated recommendations.
I'm really surprised at the state of security by many of these suggestions. In an ideal world, the apache user should have no write ability, except perhaps to some temp directory. Instead, people are recommending providing long-standing write permissions to the entire DocumentRoot where the apache user can read and write virtually every file, potentially taking down the entire website if there's ever an apache vulnerability.
Even with that aside, the sgid option didn't work for me because the umask is still 0022, which creates new directories without write permission for the group. I've searched and searched, and there does not appear to be a working solution to changing the umask for the apache user in fedora24.
Other suggestions involve basically an suid script (suPHP), but it seems complicated and security-prone. Another called PHP-FPM looks very involved and also isn't included with the default apache install due to security implications.
The suPHP option seems quite old, with no updates since 2013 that I can find. I'm open to the PHP-FPM option, but I wanted to first ask the list how they're handing the situation?
Are you making the remote user (sFTP, etc) the same as apache? Are you using PHP-FPM? If so, is there a Fedora guide you recommend? Are you changing the umask to be able to put the two users in the same group? If so, how? I tried editing the unit service but that didn't have any effect.
Any ideas greatly appreciated.
On 10/25/2016 06:53 PM, Alex wrote:
The problem I was having was with the user doing local modifications (joomadmin) not being able to modify files uploaded or changed by the joomla apache user (apache).
Numerous suggestions were made, including changing all the files to be sgid write, adding the users to a common group, and other, more complicated recommendations.
I'm really surprised at the state of security by many of these suggestions.
First, add the joomlaadmin to the apache group: # usermod -a -G apache joomadmin
Second, change the apache umask. Use "systemctl edit httpd" and enter two lines in the editor that opens: [Service] UMask=0002
Third, restart the httpd service with "systemctl restart httpd"
There you go. httpd will create files that are writable by the group apache, and joomadmin is a member of that group, so it can modify those files. You haven't given apache any new permissions.
I have tested this specific process on Fedora 24.
Hi,
On Thu, Oct 27, 2016 at 4:09 PM, Gordon Messmer gordon.messmer@gmail.com wrote:
On 10/25/2016 06:53 PM, Alex wrote:
The problem I was having was with the user doing local modifications (joomadmin) not being able to modify files uploaded or changed by the joomla apache user (apache).
Numerous suggestions were made, including changing all the files to be sgid write, adding the users to a common group, and other, more complicated recommendations.
I'm really surprised at the state of security by many of these suggestions.
First, add the joomlaadmin to the apache group: # usermod -a -G apache joomadmin
Second, change the apache umask. Use "systemctl edit httpd" and enter two lines in the editor that opens: [Service] UMask=0002
Third, restart the httpd service with "systemctl restart httpd"
There you go. httpd will create files that are writable by the group apache, and joomadmin is a member of that group, so it can modify those files. You haven't given apache any new permissions.
I have tested this specific process on Fedora 24.
I've actually already done these exact steps, and it doesn't work (on fedora23). When you say you've tested it, do you mean you tested the steps above, or you did something to confirm afterwards that its umask is 0002?
# cat /etc/systemd/system/httpd.service.d/override.conf [Service] UMask=0002 # systemctl restart httpd # su - apache -s /bin/bash -bash-4.3$ umask 0022
Thanks, Alex
On 10/27/2016 01:44 PM, Alex wrote:
I've actually already done these exact steps, and it doesn't work (on fedora23). When you say you've tested it, do you mean you tested the steps above, or you did something to confirm afterwards that its umask is 0002?
I created a php script that created a new file. Before the change, the file's mode was 0644. After the change, the mode was 0664.
You previously said that you'd tried to override the umask by editing /etc/systemd/system/multi-user.target.wants/httpd.service, which is not the same file.
Follow the steps I offered, exactly.
# cat /etc/systemd/system/httpd.service.d/override.conf [Service] UMask=0002 # systemctl restart httpd # su - apache -s /bin/bash -bash-4.3$ umask 0022
The process I documented doesn't change the umask for the user, only for the httpd process started by systemd.
On 10/27/2016 02:14 PM, Joe Zeff wrote:
On 10/27/2016 01:57 PM, Gordon Messmer wrote:
I created a php script that created a new file. Before the change, the file's mode was 0644. After the change, the mode was 0664.
Did you run the script after the change, or simply make the change and check the mode again?
Since I was testing a php script that *created* a file, I deleted the file before the second test and loaded the php page via my browser, again.
On 10/27/2016 04:16 PM, Gordon Messmer wrote:
Since I was testing a php script that *created* a file, I deleted the file before the second test and loaded the php page via my browser, again.
Thank you. I was concerned that you'd forgotten that changes to umask only apply to files created after the change.
Hi,
On Thu, Oct 27, 2016 at 4:57 PM, Gordon Messmer gordon.messmer@gmail.com wrote:
On 10/27/2016 01:44 PM, Alex wrote:
I've actually already done these exact steps, and it doesn't work (on fedora23). When you say you've tested it, do you mean you tested the steps above, or you did something to confirm afterwards that its umask is 0002?
I created a php script that created a new file. Before the change, the file's mode was 0644. After the change, the mode was 0664.
You previously said that you'd tried to override the umask by editing /etc/systemd/system/multi-user.target.wants/httpd.service, which is not the same file.
Follow the steps I offered, exactly.
# cat /etc/systemd/system/httpd.service.d/override.conf [Service] UMask=0002 # systemctl restart httpd # su - apache -s /bin/bash -bash-4.3$ umask 0022
The process I documented doesn't change the umask for the user, only for the httpd process started by systemd.
Ah yes, of course, thanks. This UMask change has been in place for more than a week, and the joomla developers have still been complaining about write problems, but I'll test manually with joomla again. Specifically, uploading new modules have been created with 0644 and 0755.
On 10/27/2016 01:44 PM, Alex wrote:
Hi,
On Thu, Oct 27, 2016 at 4:09 PM, Gordon Messmer gordon.messmer@gmail.com wrote:
On 10/25/2016 06:53 PM, Alex wrote:
The problem I was having was with the user doing local modifications (joomadmin) not being able to modify files uploaded or changed by the joomla apache user (apache).
Numerous suggestions were made, including changing all the files to be sgid write, adding the users to a common group, and other, more complicated recommendations.
I'm really surprised at the state of security by many of these suggestions.
First, add the joomlaadmin to the apache group: # usermod -a -G apache joomadmin
Second, change the apache umask. Use "systemctl edit httpd" and enter two lines in the editor that opens: [Service] UMask=0002
Third, restart the httpd service with "systemctl restart httpd"
There you go. httpd will create files that are writable by the group apache, and joomadmin is a member of that group, so it can modify those files. You haven't given apache any new permissions.
I have tested this specific process on Fedora 24.
I've actually already done these exact steps, and it doesn't work (on fedora23). When you say you've tested it, do you mean you tested the steps above, or you did something to confirm afterwards that its umask is 0002?
# cat /etc/systemd/system/httpd.service.d/override.conf [Service] UMask=0002 # systemctl restart httpd # su - apache -s /bin/bash -bash-4.3$ umask 0022
Alex, the change to the override.conf file affects ONLY the httpd _process_ started by systemd. It does NOT change the umask for the apache _user_ (which is what you tested).
To only way to verify the change "took" is to have the httpd process create a file and check the mode of the file created. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - A day for firm decisions!!! Well, then again, maybe not! - ----------------------------------------------------------------------
Hi,
I've actually already done these exact steps, and it doesn't work (on fedora23). When you say you've tested it, do you mean you tested the steps above, or you did something to confirm afterwards that its umask is 0002?
# cat /etc/systemd/system/httpd.service.d/override.conf [Service] UMask=0002 # systemctl restart httpd # su - apache -s /bin/bash -bash-4.3$ umask 0022
Alex, the change to the override.conf file affects ONLY the httpd _process_ started by systemd. It does NOT change the umask for the apache _user_ (which is what you tested).
To only way to verify the change "took" is to have the httpd process create a file and check the mode of the file created.
Yes, thanks. I still need to test it for joomla through the apache user, but as I mentioned in a previous email a few minutes ago, it still appears to be 0022.
How is it set for the normal user? I've modified /etc/bashrc (and even /etc/profile), and the apache user doesn't have a .bashrc or .bash_profile, and it's still 0022.
This is important because the "joomadmin" user will be manipulating these files via sFTP or scp.
I've also tried modifying the Subsystem variable to first set the umask before running /usr/libexec/openssh/sftp-server, and the Windows sFTP client they're using apparently can't handle this.
On 10/27/2016 02:27 PM, Alex wrote:
Hi,
I've actually already done these exact steps, and it doesn't work (on fedora23). When you say you've tested it, do you mean you tested the steps above, or you did something to confirm afterwards that its umask is 0002?
# cat /etc/systemd/system/httpd.service.d/override.conf [Service] UMask=0002 # systemctl restart httpd # su - apache -s /bin/bash -bash-4.3$ umask 0022
Alex, the change to the override.conf file affects ONLY the httpd _process_ started by systemd. It does NOT change the umask for the apache _user_ (which is what you tested).
To only way to verify the change "took" is to have the httpd process create a file and check the mode of the file created.
Yes, thanks. I still need to test it for joomla through the apache user, but as I mentioned in a previous email a few minutes ago, it still appears to be 0022.
How is it set for the normal user? I've modified /etc/bashrc (and even /etc/profile), and the apache user doesn't have a .bashrc or .bash_profile, and it's still 0022.
Where did you set it? By default /etc/profile changes the umask for interactive shells to 0002 under the following criteria:
if the user ID is > 199 AND the EUID (by name) is the same as the EGID (by name)
Otherwise the umask is set to 0022. By default, /etc/bashrc does precisely the same for _non-login_ bash shells.
Just to prove you can change the umask via /etc/profile:
[root@prophead ~]# su - apache -s /bin/bash -c "umask" 0022 [root@prophead ~]# echo "umask 0002" >>/etc/profile [root@prophead ~]# su - apache -s /bin/bash -c "umask" 0002
Note that this affects ALL users' interactive shells, so delete that line we just added from the end of /etc/profile as soon as possible after you're satisfied it works.
I'd highly recommend you add code to both /etc/profile and /etc/bashrc to selectively change the umask for the apache user (on my machine, that's UID 48).
This is important because the "joomadmin" user will be manipulating these files via sFTP or scp.
I've also tried modifying the Subsystem variable to first set the umask before running /usr/libexec/openssh/sftp-server, and the Windows sFTP client they're using apparently can't handle this.
Uh, how? The /etc/ssh/sshd_config line should read:
Subsystem sftp /usr/libexec/openssh/sftp-server -u 0002
and you must restart sshd via "systemctl restart sshd.service" as /etc/ssh/sshd_config is only read when sshd starts up.
---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - A day for firm decisions!!! Well, then again, maybe not! - ----------------------------------------------------------------------
Hi,
To only way to verify the change "took" is to have the httpd process create a file and check the mode of the file created.
Yes, thanks. I still need to test it for joomla through the apache user, but as I mentioned in a previous email a few minutes ago, it still appears to be 0022.
How is it set for the normal user? I've modified /etc/bashrc (and even /etc/profile), and the apache user doesn't have a .bashrc or .bash_profile, and it's still 0022.
Where did you set it? By default /etc/profile changes the umask for interactive shells to 0002 under the following criteria:
if the user ID is > 199 AND the EUID (by name) is the same as the EGID (by name)
I misinterpreted that when I first read it.
Otherwise the umask is set to 0022. By default, /etc/bashrc does precisely the same for _non-login_ bash shells.
Just to prove you can change the umask via /etc/profile:
[root@prophead ~]# su - apache -s /bin/bash -c "umask" 0022 [root@prophead ~]# echo "umask 0002" >>/etc/profile [root@prophead ~]# su - apache -s /bin/bash -c "umask" 0002Note that this affects ALL users' interactive shells, so delete that line we just added from the end of /etc/profile as soon as possible after you're satisfied it works.
I'd highly recommend you add code to both /etc/profile and /etc/bashrc to selectively change the umask for the apache user (on my machine, that's UID 48).
This is what I've done now, and it works well, thanks.
This is important because the "joomadmin" user will be manipulating these files via sFTP or scp.
I've also tried modifying the Subsystem variable to first set the umask before running /usr/libexec/openssh/sftp-server, and the Windows sFTP client they're using apparently can't handle this.
Uh, how? The /etc/ssh/sshd_config line should read:
Subsystem sftp /usr/libexec/openssh/sftp-server -u 0002and you must restart sshd via "systemctl restart sshd.service" as /etc/ssh/sshd_config is only read when sshd starts up.
I had set umask prior to spawning sftp-server, as in 'umask 0002; /usr/libexec/openssh/sftp-server'.
This whole issue started with trying to figure out which is the preferred method for managing access to files by apache and a web admin.
Many recommended suPHP, while others recommended other, more complicated modules like PHP-FPM. I was surprised there was no more comprehensive joomla or apache doc with recommended best practices or as part of their security documentation that described more clearly how best to secure the DocumentRoot while allowing remote access by other users.
Meanwhile, a security vulnerability in apache leading to a shell means it then has complete write access to the site.
Gordon Messmer wrote:
Assume that we don't know what your process is, and be specific about how you're uploading new modules, please.
I'm referring to the procedure typically used by joomla admins through the web-based admin interface included with joomla. It logs in as a system user then I believe uses sftp to upload files from the local desktop or somewhere on the joomla system.
On 10/27/2016 05:48 PM, Alex wrote:
Hi,
To only way to verify the change "took" is to have the httpd process create a file and check the mode of the file created.
Yes, thanks. I still need to test it for joomla through the apache user, but as I mentioned in a previous email a few minutes ago, it still appears to be 0022.
How is it set for the normal user? I've modified /etc/bashrc (and even /etc/profile), and the apache user doesn't have a .bashrc or .bash_profile, and it's still 0022.
Where did you set it? By default /etc/profile changes the umask for interactive shells to 0002 under the following criteria:
if the user ID is > 199 AND the EUID (by name) is the same as the EGID (by name)I misinterpreted that when I first read it.
Otherwise the umask is set to 0022. By default, /etc/bashrc does precisely the same for _non-login_ bash shells.
Just to prove you can change the umask via /etc/profile:
[root@prophead ~]# su - apache -s /bin/bash -c "umask" 0022 [root@prophead ~]# echo "umask 0002" >>/etc/profile [root@prophead ~]# su - apache -s /bin/bash -c "umask" 0002Note that this affects ALL users' interactive shells, so delete that line we just added from the end of /etc/profile as soon as possible after you're satisfied it works.
I'd highly recommend you add code to both /etc/profile and /etc/bashrc to selectively change the umask for the apache user (on my machine, that's UID 48).
This is what I've done now, and it works well, thanks.
This is important because the "joomadmin" user will be manipulating these files via sFTP or scp.
I've also tried modifying the Subsystem variable to first set the umask before running /usr/libexec/openssh/sftp-server, and the Windows sFTP client they're using apparently can't handle this.
Uh, how? The /etc/ssh/sshd_config line should read:
Subsystem sftp /usr/libexec/openssh/sftp-server -u 0002and you must restart sshd via "systemctl restart sshd.service" as /etc/ssh/sshd_config is only read when sshd starts up.
I had set umask prior to spawning sftp-server, as in 'umask 0002; /usr/libexec/openssh/sftp-server'.
Yeah, that's wrong. The "-u 0002" option to the sftp-server is there specifically to handle this sort of thing.
This whole issue started with trying to figure out which is the preferred method for managing access to files by apache and a web admin.
Many recommended suPHP, while others recommended other, more complicated modules like PHP-FPM. I was surprised there was no more comprehensive joomla or apache doc with recommended best practices or as part of their security documentation that described more clearly how best to secure the DocumentRoot while allowing remote access by other users.
PHP-FPM isn't that complicated. PHP runs as a completely separate process (under its own user and group) from Apache. Apache communicates with it via either IP or Unix sockets. Therefore the files that php deals with can have completely different owners and groups and permissions from what Apache has.
If you want to use the worker-thread model of Apache, you MUST use PHP-FPM because PHP isn't thread-safe (well, PHP itself is thread- safe...some of the libraries used in PHP aren't). In fact, the PHP stuff doesn't even have to be on the same physical machine as Apache. We actually have a set of systems that do nothing but run PHP and Apache on the web nodes "talk" to them via IP sockets. We can keep things separate that way and grow the number of PHP machines to handle workloads (they're behind a load balancer with "sticky" mode set). ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - Denial. It ain't just a river in Egypt anymore! - ----------------------------------------------------------------------
On 10/27/2016 05:48 PM, Alex wrote:
I'm referring to the procedure typically used by joomla admins through the web-based admin interface included with joomla. It logs in as a system user then I believe uses sftp to upload files from the local desktop or somewhere on the joomla system.
As best I can tell, extensions are normally uploaded as zip files. It should be noted, then, that the umask doesn't appear to affect that. zip files contain some information about the permissions of the files they contain, and at least the system "unzip" utility will honor those. You might be chasing a wild goose if you're trying to change apache's umask to address this.
Instead you may need to use the "manual install" process and set the permissions on files manually:
https://docs.joomla.org/Installing_an_extension
As a security bonus, I would anticipate that manual installation would mean that your extensions aren't owned by the apache use, and can be installed with no write access for the apache group. So, that's something to think about.
Hi,
On Tue, Nov 1, 2016 at 5:31 PM, Gordon Messmer gordon.messmer@gmail.com wrote:
On 10/27/2016 05:48 PM, Alex wrote:
I'm referring to the procedure typically used by joomla admins through the web-based admin interface included with joomla. It logs in as a system user then I believe uses sftp to upload files from the local desktop or somewhere on the joomla system.
As best I can tell, extensions are normally uploaded as zip files. It should be noted, then, that the umask doesn't appear to affect that. zip files contain some information about the permissions of the files they contain, and at least the system "unzip" utility will honor those. You might be chasing a wild goose if you're trying to change apache's umask to address this.
Instead you may need to use the "manual install" process and set the permissions on files manually:
https://docs.joomla.org/Installing_an_extension
As a security bonus, I would anticipate that manual installation would mean that your extensions aren't owned by the apache use, and can be installed with no write access for the apache group. So, that's something to think about.
That's another great point. Thanks so much for your help, and follow-through.
On 10/27/2016 02:27 PM, Alex wrote:
How is it set for the normal user? I've modified /etc/bashrc (and even /etc/profile), and the apache user doesn't have a .bashrc or .bash_profile, and it's still 0022.
It's difficult to tell what you're doing wrong, because you aren't being specific about what you're changing. /etc/profile is used for login shells. /etc/bashrc will be used for interactive shells, but only if the user's ~/.bashrc exists and loads it.
For example, the "apache" user doesn't have a .bashrc file, so setting a custom umask in /etc/profile or /etc/profile.d/whatever.sh will work, but /etc/bashrc won't.
[root@vagabond ~]# su - -s /bin/bash apache -bash-4.3$ umask 0022 -bash-4.3$ logout [root@vagabond ~]# echo umask 002 >> /etc/profile [root@vagabond ~]# su - -s /bin/bash apache -bash-4.3$ umask 0002 -bash-4.3$ logout [root@vagabond ~]# vi /etc/profile [root@vagabond ~]# su - -s /bin/bash apache -bash-4.3$ umask 0022 -bash-4.3$ logout [root@vagabond ~]# echo umask 002 >> /etc/bashrc [root@vagabond ~]# su - -s /bin/bash apache -bash-4.3$ umask 0022
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
This is in docs.joomla.org:
"PHP Being Run as an Apache Module.
This causes ownership issues and thus permission problems which will lead to security issues. It is better to select a server setup/host that runs php as a cgi process (such as cgi-fcgi) along with using phpSuExec or a similar configuration."
Could this be the source of your problems?
Put the service file back the way it was.
It's best if you can identify which directories Joomla needs write access to limit exposure. For Wordpress it's /path/to/wordpress/DocumentRoot/wp-content/{plugins,themes,upgrade,uploads} so: rw_dirs="plugins themes upgrade uploads" if you can't identify them, you have to open up the whole tree: rw_dirs="."
Now do this: cd /path/to/joomla/DocumentRoot chmod -R apache:apache $rw_dirs find $rw_dirs -type d -exec chmod 2770 {} ; find $rw_dirs -type f -exec chmod 660 {} ;
There's more to do if you're running selinux. But try the above and report back.
Hope this helps, Bill
On 9/6/2016 4: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:
[Unit] Description=The Apache HTTP Server After=network.target remote-fs.target nss-lookup.target
[Service] Type=notify Environment=LANG=C Umask=0006
ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND ExecReload=/usr/sbin/httpd $OPTIONS -k graceful # Send SIGWINCH for graceful stop KillSignal=SIGWINCH KillMode=mixed PrivateTmp=true
[Install] WantedBy=multi-user.target
The problem is that the files are owned by the joomla user, but also need to have access (both read and write) to be able to modify some files within the document root.
Does anyone have any suggestions on how to set umask for the apache user?
I'm also interested in recommended permissions settings for the joomla document root.
Thanks, Alex -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://lists.fedoraproject.org/admin/lists/users@lists.fedoraproject.org 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
Hi,
Now do this: cd /path/to/joomla/DocumentRoot chmod -R apache:apache $rw_dirs find $rw_dirs -type d -exec chmod 2770 {} ; find $rw_dirs -type f -exec chmod 660 {} ;
You mean chown above, but yes, I've also thought about setting everything sgid.
Someone in another forum recommended mod_suphp (http://www.suphp.org/Home.html). It appears to modify how apache directly writes files. However, I'm not sure that's a good option, particularly given that the website lacks any indication of there being any current development.
Anyone have any experience with it?
Thanks, Alex
Hi,
On Thu, Sep 8, 2016 at 12:32 PM, Alex mysqlstudent@gmail.com wrote:
Hi,
Now do this: cd /path/to/joomla/DocumentRoot chmod -R apache:apache $rw_dirs find $rw_dirs -type d -exec chmod 2770 {} ; find $rw_dirs -type f -exec chmod 660 {} ;
You mean chown above, but yes, I've also thought about setting everything sgid.
Someone in another forum recommended mod_suphp (http://www.suphp.org/Home.html). It appears to modify how apache directly writes files. However, I'm not sure that's a good option, particularly given that the website lacks any indication of there being any current development.
Anyone have any experience with it?
After a little more research, it appears suEXEC is what's now used more commonly (http://httpd.apache.org/docs/current/suexec.html).
This apparently provides the ability for the ability to run CGI and SSI programs under user IDs different from the user ID of the calling web server without having to modify file permissions.
On 09/08/2016 10:20 AM, Alex wrote:
Hi,
Here's an idea. Get an account on DigitalOcean. Create a droplet using their "One-click apps". They have one called "Joomla 3.6.2 on 14.04" (14.04 is a version of ubuntu).
Explore the Apache config and the Joomla config. Checkout permissioning and ownership. Probably faster than playing "what if".
If you pick the smallest droplet it's $5 per month charged by the hour. If it took a week to figure it out you'd be out less than $1.25 and you would have learned how to have a host in the cloud at the same time.
Why didn't you try it? It works for me.
I spent my time trying to help and you dismissed it WITHOUT reason.
Not cool. Bill
On 9/8/2016 12:32 PM, Alex wrote:
Hi,
Now do this: cd /path/to/joomla/DocumentRoot chmod -R apache:apache $rw_dirs find $rw_dirs -type d -exec chmod 2770 {} ; find $rw_dirs -type f -exec chmod 660 {} ;
You mean chown above, but yes, I've also thought about setting everything sgid.
Someone in another forum recommended mod_suphp (http://www.suphp.org/Home.html). It appears to modify how apache directly writes files. However, I'm not sure that's a good option, particularly given that the website lacks any indication of there being any current development.
Anyone have any experience with it?
Thanks, Alex -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://lists.fedoraproject.org/admin/lists/users@lists.fedoraproject.org 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
Hi,
On Thu, Sep 8, 2016 at 8:17 PM, Bill Shirley bshirley@memphis.apirx.biz wrote:
Why didn't you try it? It works for me.
I spent my time trying to help and you dismissed it WITHOUT reason.
Not cool.
I'm sorry you feel that I've dismissed your offer to help. I haven't. We're just having a discussion. I'm very familiar with how suid/sgid works, and have in fact done that for now. I appreciate that you take the issue so personally; it tells me you're sincerely interested in helping.
There was still a problem with ssh due to ownership of the ssh user separate from apache which had to be changed afterwards.
The reason I was exploring other possibilities is because generally speaking the apache user shouldn't have write privileges in the document root. If there was ever an apache compromise leading to a shell, it would put in jeopardy the entire website. I'd like to avoid that.
I'm disappointed there isn't more explicit information on directory permissions in the joomla documentation. I believe the reason for that is because they recommend the mod_suphp module for managing permissions.
Thanks, Alex
Allegedly, on or about 09 September 2016, Alex sent:
The reason I was exploring other possibilities is because generally speaking the apache user shouldn't have write privileges in the document root. If there was ever an apache compromise leading to a shell, it would put in jeopardy the entire website. I'd like to avoid that.
The barely improved solution is to not let it write to the document root, but only to a sub-directory.
I would have thought, though, that the way to do this is to not allow any writes to anything in the document root, but for your publishing scripts to write to its own (separate) database, in a rigidly controlled manner (by the authoring software), and for the webserver to read from it.
-
Alex -
Bill Shirley -
Emmett Culley -
Gordon Messmer -
Joe Zeff -
lst_manage＠webengineer.com
-
Mike Wright -
Rick Stevens -
Tim