Apache write permissions even with 777

Rajasekhar Atteri · 03-14-2013, 04:13 AM

My php program is unable to write to a config file in my document root.

I have even set file permissions to 777 (bad idea - I know but just to debug the issue) and still am unable to write.

So obviously something within Apache is doing its own permissions check in addition to file system permissions.

Please help!

My virtualhost is setup thus:

<VirtualHost *:80>
ServerName localhost
ServerAdmin ratteri@gmail.com
ServerAlias saraslights
<Directory "/var/www/html/opencart">
AllowOverride None
Order allow,deny
allow from all
</Directory>
DocumentRoot "/var/www/html/opencart"
ErrorLog "logs/saraslights-errors.log"
CustomLog "logs/saraslights-access.log" common
</VirtualHost>

acid_kewpie · 03-14-2013, 04:18 AM

sounds like SELinux to me, nothign in /var/log/secure abuot violations there?

Rajasekhar Atteri · 03-14-2013, 07:27 AM

Thanks Chris!

That was it. Disabling selinux solved the issue

But instead of disabling selinux is there any specific setting within selinux that I can modify
to allow apache to modify files in the document root?

It seems like a shame to throw away selinux simply because of this issue.

acid_kewpie · 03-14-2013, 08:05 AM

my SELinux isn't great, but I think you can reset the context of this new directoty you created. if you do an "ls -lZ /var/www/html" ls will show you the SELinux contexts of the directories, and I would think that your opencart one is wrong. If that's the case you can use chcon to change the context of the relevant things, or restorecon of the whole /var/www/html location whcih will set contexts based on a atandard database of common paths.

There may be other specific apache tuning issues in SELinux though, feel free to post the actual vioaltions in the logs.

Rajasekhar Atteri · 03-14-2013, 08:42 AM

Here is the directory context info. I dont know how to interpret this.

drwxr-xr-x. apache apache unconfined_u

bject_r:httpd_sys_content_t:s0 opencart
drwxr-xr-x. apache apache unconfined_u

bject_r:httpd_sys_content_t:s0 wordpress

and from var/log/messages :
Mar 14 19:07:48 dosa setroubleshoot: SELinux is preventing /usr/sbin/httpd from write access on the directory logs. For complete SELinux messages. run sealert -l 11dc8f16-155f-455a-9856-3cb0853ad7b6
Mar 14 19:07:48 dosa setroubleshoot: SELinux is preventing /usr/sbin/httpd from write access on the directory cache. For complete SELinux messages. run sealert -l 11dc8f16-155f-455a-9856-3cb0853ad7b6
Mar 14 19:07:48 dosa setroubleshoot: SELinux is preventing /usr/sbin/httpd from write access on the directory logs. For complete SELinux messages. run sealert -l 11dc8f16-155f-455a-9856-3cb0853ad7b6

Rajasekhar Atteri · 03-14-2013, 08:48 AM

and here it is for the cache directory...

-rwxr-xr-x. apache apache unconfined_u

bject_r:httpd_sys_content_t:s0 startup.php

cache:
-rw-r--r--. apache apache system_u

bject_r:httpd_sys_content_t:s0 cache.currency.1363267516
-rw-r--r--. apache apache system_u

bject_r:httpd_sys_content_t:s0 cache.language.1363267516
-rw-r--r--. apache apache system_u

bject_r:httpd_sys_content_t:s0 cache.store.1363267513
-rwxr-xr-x. apache apache unconfined_u

bject_r:httpd_sys_content_t:s0 index.html

acid_kewpie · 03-14-2013, 08:55 AM

ok so you already did what the messages logs say, right?

oldscratch · 03-14-2013, 09:02 AM

It would indeed be a shame to throw away SELinux because of a configuration issue, and its definitely worth spending some time figuring it out.

Did you run sealert as the log messages indicated?

You could also try something like this:

Code:

sealert -a /var/log/audit/audit.log

That command will scan your audit log for SELinux messages and should propose some policy changes that you can make to allow the disallowed actions.

Instead of disabling SELinux completely, you can set it to run in permissive mode. That way, the violations will still be logged and you'll be able to work out the required policy changes. If you disable it completely, you won't get any logs to work from. On a Red Hat system, you can find the settings in /etc/selinux/config. You can also switch a running system from permissive to enforcing and vice-versa with the "setenforce" command, like this:

Code:

# set selinux in permissive mode (log violations, but don't enforce)
setenforce 0

# set selinux in enforcing mode (log and enforce)
setenforce 1

You can see the current enforcing mode with the "getenforce" command:

Here are the commands in action:

Code:

[root@bigdaddy ~]# getenforce
Enforcing

[root@bigdaddy ~]# setenforce 0
[root@bigdaddy ~]# getenforce
Permissive

[root@bigdaddy ~]# setenforce 1
[root@bigdaddy ~]# getenforce
Enforcing

chrism01 · 03-14-2013, 08:09 PM

You need to fix the SELinux on the dir itself, not just the files therein. Note its complaining about both the 'logs' dir as well as the 'cache' dir.

For the php script you'll need a suitable SELinux type httpd_sys_script_xxxx http://beginlinux.com/server_trainin...he-and-selinux

sundialsvcs · 03-14-2013, 09:22 PM

Suggestion: work within the world-view advocated by SELinux, instead of working against it.

"Apache," after all, "is just another ordinary user." The web-service, Apache, is "somebody (apache)" therefore with some associated set of credentials. It shouldn't be given a blank check: like every other "ordinary user," it should be restricted to: "what it needs to do, and not one whit more."

The "Unix permissions mask" model really will not apply here: you're dealing with Access Control Lists (ACLs) or their SELinux equivalent from the very start. The "permissions mask" is vastly too simplistic, and it need not apply. You've never been limited to that, anyway . . .

oldscratch · 03-15-2013, 05:31 AM

sundialsvcs has it right.

I normally try to avoid responding to questions with "You don't want to do that", but in this case, do you really want Apache writing to a config file? Normally, I'd set Apache up to be able to write to data files in specific data directories, its own log files, tmp files, session cookies, and any DB's required for the webapps. Allowing Apache to write configs or code, create dirs, download files, etc. is asking for trouble.

So really, it sounds like SELinux is doing exactly what its supposed to do, and if you follow my advice from above without understanding what you're doing and why, you're going to lose a lot of the protection SELinux offers.

jpollard · 03-15-2013, 08:14 AM

http://www.linuxhomenetworking.com/w...xt_File_Labels

The table isn't quite complete. The entries listed are for those files owned by apache...

User files (normally accessed via the public html directive) have a different label that users can make use of:

httpd_user_content_t for read only access
httpd_user_rw_content_t for read/write access

Directories that are to receive uploads/data file creation operations must have the "rw" forms. Data files must have the "rw" if they are to be written to.

In addition to the mandatory labels, the files must be readable (or read/write) by the apache user.

Created files will always be owned by the apache user.