[SOLVED] Apache can't open /etc/shadow: permission denied.

ThaMe90 · 09-19-2011, 08:52 AM

I installed Apache (httpd) on a couple of Rhel6 machines. All different hardware, software is equal among all installations. Yet on 3 out of 4 installations, Apache can't access the /etc/shadow file for authentication purposes. What I get is

Code:

[Mon Sep 19 15:28:06 2011] [error] [client 192.168.10.172] (13)Permission denied: Could not open password file: /etc/shadow
[Mon Sep 19 15:28:06 2011] [error] [client 192.168.10.172] PAM: user 'root' - not authenticated: System error

I can't seem to figure out why it hasn't got the correct permissions, as I've changed them times and times over again. I've changed /etc/shadow's permissions to 644, and /etc's and /'s permissions to 755. Yet after restarting httpd, I still can't access the server via a web-browser.

I've also tried to access the file not with PAM, but with an external program, pwauth, in combination with mod_authnz_external. But this yielded the same results.

bathory · 09-19-2011, 12:05 PM

Hi,

I would suspect SELinux that is preventing apache user to read /etc/shadow even after changing permissions.
You can use mod_auth_shadow for this.
And please restore the permissions back to their original status, if you want to be secure.

Regards

ThaMe90 · 09-20-2011, 04:02 AM

Thanks for your reply bathory,

Mod_auth_shadow was the next module I was going to try. Will see what that will do.

ThaMe90 · 09-20-2011, 04:47 AM

What I get with mod_auth_shadow is the following:

Code:

[Tue Sep 20 11:33:59 2011] [error] [client 192.168.10.142] (13)Permission denied: Could not open password file: /etc/shadow
/usr/local/sbin/validate: No read access to /etc/shadow.  This program must be suid or sgid.
[Tue Sep 20 11:33:59 2011] [error] [client 192.168.10.142] Invalid password entered for user root

This was after I reset the permissions on the files. Yet it seems that it still isn't accessing the shadow file correctly. I've tried setting chmod u+s on the /usr/local/sbin/validate program, but this doesn't help aswell. Maybe g+s will work. Let me try.

bathory · 09-20-2011, 05:20 AM

Hi,

Quote:

I've tried setting chmod u+s on the /usr/local/sbin/validate program, but this doesn't help aswell. Maybe g+s will work. Let me try.

Running validate suid should be enough, since /etc/shadow permissions are 400 (r-------). Disable SELinux, at least temporarily and see if that's the case.

unSpawn · 09-20-2011, 05:34 AM

Quote:

Originally Posted by ThaMe90

Code:

[Tue Sep 20 11:33:59 2011] [error] [client 192.168.10.142] Invalid password entered for user root

...and if you're going to test accounts then use an unprivileged user account. Root should not ever be allowed to log in over any network, period.

unSpawn · 09-20-2011, 05:35 AM

Quote:

Originally Posted by bathory

Disable SELinux, at least temporarily and see if that's the case.

Please don't. Use 'setsebool -P httpd_disable_trans 1' instead. Before doing that best review any messages let in syslog or /var/log/audit/audit.log.

bathory · 09-20-2011, 05:45 AM

Quote:

Originally Posted by unSpawn

Please don't. Use 'setsebool -P httpd_disable_trans 1' instead. Before doing that best review any messages let in syslog or /var/log/audit/audit.log.

I asked OP to disable SELinux temporarily to test if that's the case he can't authenticate against /etc/shadow. I completely detest the idea to use /etc/shadow to authenticate users through apache, especially without using https

Regards

unSpawn · 09-20-2011, 05:57 AM

What I mean is that you don't have to disable SELinux completely just to test this: please see 'man httpd_selinux' for an explanation of booleans available in httpd_t.

ThaMe90 · 09-20-2011, 06:08 AM

Quote:

Originally Posted by unSpawn

...and if you're going to test accounts then use an unprivileged user account. Root should not ever be allowed to log in over any network, period.

It isn't my idea to use root as a network login, but for now, it is a (bad?) custom where I work. There is talk to change that to a PostgreS database login, but that hasn't been realised yet.

ThaMe90 · 09-20-2011, 06:45 AM

Quote:

Originally Posted by unSpawn

Please don't. Use 'setsebool -P httpd_disable_trans 1' instead. Before doing that best review any messages let in syslog or /var/log/audit/audit.log.

I've checked the man page for httpd_selinux, but there is no boolean httpd_disable_trans described there... So I won't be able to change the value of it. I have actually tried setting the value, but I got this error message:

Code:

libsemanage.dbase_llist_set: record not found in the database (No such file or directory).
libsemanage.dbase_llist_set: could not set record value (No such file or directory).
Could not change boolean httpd_disable_trans
Could not change policy booleans

unSpawn · 09-20-2011, 06:57 AM

Then I wonder if your install came loaded with the SELinux targeted policy and all software was installed using official RPM packages and not source tarballs? As root running 'getsebool -a|grep httpd' should indicate available booleans.

ThaMe90 · 09-20-2011, 07:05 AM

Quote:

Originally Posted by unSpawn

Then I wonder if your install came loaded with the SELinux targeted policy and all software was installed using official RPM packages and not source tarballs? As root running 'getsebool -a|grep httpd' should indicate available booleans.

I installed everything from official RPM packages.

On a side note, it seems that SELinux is completely shut off on the system that did work.
Disabling SELinux on a system that had it enabled causes a Service Temporarily Unavailable message in my browser...

getsebool -a|grep httpd yields the following list of booleans:

Code:

allow_httpd_anon_write --> off
allow_httpd_mod_auth_ntlm_winbind --> off
allow_httpd_mod_auth_pam --> off
allow_httpd_sys_script_anon_write --> off
httpd_builtin_scripting --> on
httpd_can_check_spam --> off
httpd_can_network_connect --> off
httpd_can_network_connect_cobbler --> off
httpd_can_network_connect_db --> off
httpd_can_network_memcache --> off
httpd_can_network_relay --> off
httpd_can_sendmail --> off
httpd_dbus_avahi --> on
httpd_enable_cgi --> on
httpd_enable_ftp_server --> off
httpd_enable_homedirs --> off
httpd_execmem --> off
httpd_read_user_content --> off
httpd_setrlimit --> off
httpd_ssi_exec --> off
httpd_tmp_exec --> off
httpd_tty_comm --> on
httpd_unified --> on
httpd_use_cifs --> off
httpd_use_gpg --> off
httpd_use_nfs --> off

unSpawn · 09-20-2011, 07:44 AM

Quote:

Originally Posted by ThaMe90

it seems that SELinux is completely shut off on the system that did work.

I'm not surprised as that's the easiest way to get things to work without being forced to experience or learn anything. Deities forfend...

Quote:

Originally Posted by ThaMe90

Disabling SELinux on a system that had it enabled causes a Service Temporarily Unavailable message in my browser...

Such client-side messages don't convey what happens server-side.

Quote:

Originally Posted by ThaMe90

getsebool -a|grep httpd yields the following list of booleans:

Code:

allow_httpd_mod_auth_pam --> off

Nice. That should be "on" before trying mod_auth_pam...

ThaMe90 · 09-20-2011, 08:28 AM

Quote:

Originally Posted by unSpawn

I'm not surprised as that's the easiest way to get things to work without being forced to experience or learn anything. Deities forfend...

I know,

Quote:

Originally Posted by unSpawn

Such client-side messages don't convey what happens server-side.

I know that aswell,

Quote:

Originally Posted by unSpawn

Nice. That should be "on" before trying mod_auth_pam...

With that boolean set to 1, I get the same error message as when I haven't set the boolean:

Code:

[Tue Sep 20 15:28:29 2011] [error] [client 192.168.10.142] (13)Permission denied: Could not open password file: /etc/shadow
[Tue Sep 20 15:28:29 2011] [error] [client 192.168.10.142] PAM: user 'root' - not authenticated: Authentication failure