Bug 818585 - selinux blocks postgresql startup
selinux blocks postgresql startup
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: sudo (Show other bugs)
5.8
All Linux
urgent Severity high
: rc
: ---
Assigned To: Daniel Kopeček
Miroslav Vadkerti
: ZStream
: 840529 841195 841484 841752 842384 (view as bug list)
Depends On:
Blocks: 435010 743405 841853 842759
  Show dependency treegraph
 
Reported: 2012-05-03 09:03 EDT by Karel Volný
Modified: 2013-01-08 02:49 EST (History)
40 users (show)

See Also:
Fixed In Version: sudo-1.7.2p1-16.el5
Doc Type: Bug Fix
Doc Text:
The sudo update RHSA-2012:0309 introduced a regression that caused the Security-Enhanced Linux (SELinux) context of the "/etc/nsswitch.conf" file to change during the installation or upgrade of the sudo package. This could cause various services confined by SELinux to no longer be permitted to access the file. In reported cases, this issue prevented PostgreSQL and Postfix from starting.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-01-08 02:49:34 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Patch for sudo.spec to address issue from comment #37 (1.47 KB, patch)
2012-08-09 08:28 EDT, Robert Scheck
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 169143 None None None 2012-07-23 05:40:43 EDT

  None (edit)
Description Karel Volný 2012-05-03 09:03:32 EDT
Description of problem:
With selinux enforcing, I can't start postgresql.
Turning selinux off (setenforce 0), I can start it.

Version-Release number of selected component (if applicable):
selinux-policy-2.4.6-327.el5.noarch

How reproducible:
always

Steps to Reproduce:
1. rm -rf /var/lib/pgsql/*
2. service postgresql start
3. cat /var/lib/pgsql/pgstartup.log
4. lsof -i tcp | grep postgre
  
Actual results:
2.
Initializing database:                                     [  OK  ]
Starting postgresql service:                               [FAILED]

3.
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.

The database cluster will be initialized with locale en_US.UTF-8.
The default database encoding has accordingly been set to UTF8.

fixing permissions on existing directory /var/lib/pgsql/data ... ok
creating directory /var/lib/pgsql/data/global ... ok
creating directory /var/lib/pgsql/data/pg_xlog ... ok
creating directory /var/lib/pgsql/data/pg_xlog/archive_status ... ok
creating directory /var/lib/pgsql/data/pg_clog ... ok
creating directory /var/lib/pgsql/data/pg_subtrans ... ok
creating directory /var/lib/pgsql/data/pg_twophase ... ok
creating directory /var/lib/pgsql/data/pg_multixact/members ... ok
creating directory /var/lib/pgsql/data/pg_multixact/offsets ... ok
creating directory /var/lib/pgsql/data/base ... ok
creating directory /var/lib/pgsql/data/base/1 ... ok
creating directory /var/lib/pgsql/data/pg_tblspc ... ok
selecting default max_connections ... 100
selecting default shared_buffers ... 1000
creating configuration files ... ok
creating template1 database in /var/lib/pgsql/data/base/1 ... ok
initializing pg_authid ... ok
enabling unlimited row size for system tables ... ok
initializing dependencies ... ok
creating system views ... ok
loading pg_description ... ok
creating conversions ... ok
setting privileges on built-in objects ... ok
creating information schema ... ok
vacuuming database template1 ... ok
copying template1 to template0 ... ok
copying template1 to postgres ... ok

Success. You can now start the database server using:

    /usr/bin/postmaster -D /var/lib/pgsql/data
or
    /usr/bin/pg_ctl -D /var/lib/pgsql/data -l logfile start

LOG:  could not translate host name "localhost", service "5432" to address: Name or service not known
WARNING:  could not create listen socket for "localhost"
FATAL:  could not create any TCP/IP sockets

4.
(nothing)


Expected results:
2.
Initializing database:                                     [  OK  ]
Starting postgresql service:                               [  OK  ]

3.
(no errors in the log)

4.
postmaste 18443 postgres    3u  IPv4 7546488      0t0  TCP localhost.localdomain:postgres (LISTEN)


Additional info:
there is no trace of any denial in audit log

trying to google for the problem, the solution usually refers to adding localhost to /etc/hosts or making it world readable
- this is not a problem on test machines, the record is there and permissions are standard:

-rw-r--r--  root root system_u:object_r:etc_t:s0       /etc/hosts

note also that resolving localhost works with other programs, like ping:

# ping localhost
PING localhost.localdomain (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=64 time=0.057 ms
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=2 ttl=64 time=0.009 ms
Comment 1 Milos Malik 2012-05-03 10:20:22 EDT
/etc directory was mislabelled on more machines and an existing dontaudit rule prevented audit daemon from writing the AVC into audit.log.
Comment 2 Milos Malik 2012-05-03 10:29:23 EDT
File /etc/nsswitch.conf was for an unknown reason labelled rpm_script_tmp_t. Programs like initdb, postgres and postmaster wanted to read it, but SELinux denied it. Following rule then caused the lack of AVCs in audit.log file:

# sesearch -s postgresql_t -t rpm_script_tmp_t -c file --audit -i
Found 1 av rules:
    dontaudit @ttr2059 rpm_script_tmp_t : file { ioctl read write getattr lock append }; 

#
Comment 3 Daniel Walsh 2012-05-03 10:38:30 EDT
That means some rpm created or edited /etc/nsswitch in the /tmp directory and then mv'd it to /etc.

Could you see if you have a rpm that does this.

rpm -qa --scripts | grep nsswitch

If we find an rpm that is doing this then we need to change this bug to that package.
Comment 4 Milos Malik 2012-05-03 10:50:29 EDT
# rpm -qa --scripts | grep nsswitch
if ! grep -q '^[[:space:]]*sudoers:' ""/etc/nsswitch.conf""; then
   # No "sudoers:" line in nsswitch.conf, add a default one
   echo ""sudoers: files ldap"" >> ""/etc/nsswitch.conf""
# Remove the "sudoers:" line from nsswitch.conf if it's not modified
if grep -q "^sudoers: files ldap$" ""/etc/nsswitch.conf""; then
   rm -f ""/var/tmp/nsswitch.conf.bak"" && \
   touch ""/var/tmp/nsswitch.conf.bak"" && \
   grep -v "^sudoers: files ldap$" ""/etc/nsswitch.conf"" > ""/var/tmp/nsswitch.conf.bak"" && \
   mv -f ""/var/tmp/nsswitch.conf.bak"" ""/etc/nsswitch.conf""
#
Comment 5 Milos Malik 2012-05-03 10:51:58 EDT
# rpm -q --scripts sudo
postinstall scriptlet (using /bin/sh):
/bin/chmod 0440 /etc/sudoers || :

if ! grep -q '^[[:space:]]*sudoers:' ""/etc/nsswitch.conf""; then
   # No "sudoers:" line in nsswitch.conf, add a default one
   echo ""sudoers: files ldap"" >> ""/etc/nsswitch.conf""
fi
postuninstall scriptlet (using /bin/sh):
# Remove the "sudoers:" line from nsswitch.conf if it's not modified
if grep -q "^sudoers: files ldap$" ""/etc/nsswitch.conf""; then
   rm -f ""/var/tmp/nsswitch.conf.bak"" && \
   touch ""/var/tmp/nsswitch.conf.bak"" && \
   grep -v "^sudoers: files ldap$" ""/etc/nsswitch.conf"" > ""/var/tmp/nsswitch.conf.bak"" && \
   mv -f ""/var/tmp/nsswitch.conf.bak"" ""/etc/nsswitch.conf""
fi
#
Comment 6 Daniel Walsh 2012-05-03 11:01:44 EDT
Sudo should be doing a restorecon after the move at the least.
Comment 10 Daniel Kopeček 2012-07-17 11:11:11 EDT
*** Bug 840529 has been marked as a duplicate of this bug. ***
Comment 11 Jason Corley 2012-07-17 16:02:07 EDT
I hit this bug today with an upgrade to sudo-1.7.2p1-14.el5_8 on a fully patched RHEL 5 system. failure mode was apache couldn't look up localhost or any other aliases in /etc/hosts and didn't log an AVC (for the same reason as noted in comment 2) while other CLI based lookups succeeded (ping, mysql cli, etc.). restorecon /etc/nsswitch.conf fixed.
Comment 12 David Spurek 2012-07-18 03:19:26 EDT
This will be fixed in version sudo-1.7.2p1-15.el5
Comment 14 Daniel Kopeček 2012-07-18 07:52:41 EDT
*** Bug 841195 has been marked as a duplicate of this bug. ***
Comment 17 Robert Scheck 2012-07-18 09:39:41 EDT
This issue affects all of our customers with RHEL 5 because it also affects
for example postfix when bound to localhost - it won't start up anymore then.
Opened case #00679219 in the Red Hat Customer Portal.
Comment 18 Robert Scheck 2012-07-18 09:41:03 EDT
By the way...and to make it nicer for the others searching for this via Google:
Postfix complains with "fatal: config variable inet_interfaces: host not found: 
localhost" for example in the log, if you have "inet_interfaces = localhost".
Comment 19 Daniel Kopeček 2012-07-19 03:56:20 EDT
*** Bug 841484 has been marked as a duplicate of this bug. ***
Comment 24 Jeff Law 2012-07-23 11:14:10 EDT
*** Bug 841752 has been marked as a duplicate of this bug. ***
Comment 25 Jeff Law 2012-07-23 12:31:22 EDT
*** Bug 842384 has been marked as a duplicate of this bug. ***
Comment 27 Thomas Uphill 2012-07-24 10:05:33 EDT
looks like nscd is also broken by this bug.
we got this in the logs:
id: nss_ldap: could not search LDAP server - Server is unavailable

Did a restorecon on /etc/nsswitch.conf and all is well again.
Comment 32 Greg Matthews 2012-07-31 05:29:36 EDT
can we get early access to a fixed version of the sudo rpm? This is severely affecting a significant number of hosts. Automount is not working, and postfix is affected.
Comment 33 Tuomo Soini 2012-07-31 05:43:08 EDT
easy work-around is command on all el5.8 machines:

restorecon /etc/nsswitch.conf
Comment 34 Greg Matthews 2012-07-31 05:46:46 EDT
(In reply to comment #33)
> easy work-around is command on all el5.8 machines:
> 
> restorecon /etc/nsswitch.conf

not so easy across many workstations where autofs is not working (and therefore key-based ssh login fails because home dirs are not available). it is not a scalable workaround.
Comment 35 Tomas Hoger 2012-07-31 09:21:17 EDT
(In reply to comment #32)
> can we get early access to a fixed version of the sudo rpm?

Greg, all such requests need to go through the Global Support Services.  Open a support ticket at:  https://access.redhat.com/support/
Comment 36 Leonard den Ottolander 2012-08-07 17:06:40 EDT
As per sudo-1.7.2p1-14.el5_8.2 this issue appears to be fixed. The post install script now restores the selinux context on /etc/nsswitch.conf.

(I'm not gonna touch the "version fixed" and "status" fields, I'll leave that to the assignee.)
Comment 37 handballbundesliga 2012-08-09 08:13:40 EDT
(In reply to comment #36)
> As per sudo-1.7.2p1-14.el5_8.2 this issue appears to be fixed. The post
> install script now restores the selinux context on /etc/nsswitch.conf.
> 
> (I'm not gonna touch the "version fixed" and "status" fields, I'll leave
> that to the assignee.)

Confirmed. However updating to sudo-1.7.2p1-14.el5_8.2 now causing the following error msg when SELinux is not being used and policycoreutils is not installed:

"1/2/var/tmp/rpm-tmp.80468: line 17: restorecon: command not found
Non-fatal POSTIN scriptlet failure in rpm package sudo-1.7.2p1-14.el5_8.2.i386
 
error: %post(sudo-1.7.2p1-14.el5_8.2.i386) scriptlet failed, exit status 127"
Comment 38 Daniel Kopeček 2012-08-09 08:22:11 EDT
(In reply to comment #37)
> (In reply to comment #36)
> > As per sudo-1.7.2p1-14.el5_8.2 this issue appears to be fixed. The post
> > install script now restores the selinux context on /etc/nsswitch.conf.
> > 
> > (I'm not gonna touch the "version fixed" and "status" fields, I'll leave
> > that to the assignee.)
> 
> Confirmed. However updating to sudo-1.7.2p1-14.el5_8.2 now causing the
> following error msg when SELinux is not being used and policycoreutils is
> not installed:
> 
> "1/2/var/tmp/rpm-tmp.80468: line 17: restorecon: command not found
> Non-fatal POSTIN scriptlet failure in rpm package
> sudo-1.7.2p1-14.el5_8.2.i386
>  
> error: %post(sudo-1.7.2p1-14.el5_8.2.i386) scriptlet failed, exit status 127"

The policycoreutils dependency is also addressed in the new build for rhbz#846974.
Comment 39 Robert Scheck 2012-08-09 08:28:25 EDT
Created attachment 603251 [details]
Patch for sudo.spec to address issue from comment #37

Exactly, I experienced the same a few moments ago - after I closed the ticket;
thus reopening case #00679219 in the Red Hat Customer Portal.

Red Hat folks: Is it really that hard to fix this issue in a appropriate time
and really sort the issue out without introducing a new one? Looks like :-(
Comment 40 Daniel Kopeček 2012-08-09 08:39:46 EDT
(In reply to comment #39)
> Created attachment 603251 [details]
> Patch for sudo.spec to address issue from comment #37
> 
> Exactly, I experienced the same a few moments ago - after I closed the
> ticket;
> thus reopening case #00679219 in the Red Hat Customer Portal.
> 
> Red Hat folks: Is it really that hard to fix this issue in a appropriate time
> and really sort the issue out without introducing a new one? Looks like :-(

Sorry for that, I've came up with the initial script which we're unnecessarily complex and where a simple sed -i would suffice. The fix for this is already ON_QA and I hope it'll be available very soon. Again, sorry for this mess.
Comment 41 Robert Scheck 2012-08-09 09:29:46 EDT
Soon means in Red Hat terms another 14 days :(
Comment 42 Murray McAllister 2012-08-13 00:20:57 EDT
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
The sudo update RHSA-2012:0309 introduced a regression that caused the Security-Enhanced Linux (SELinux) context of the "/etc/nsswitch.conf" file to change during the installation or upgrade of the sudo package. This could cause various services confined by SELinux to no longer be permitted to access the file. In reported cases, this issue prevented PostgreSQL and Postfix from starting.
Comment 43 Maarten Litmaath 2012-08-14 08:13:25 EDT
Hi all,
I am not convinced the resolution of this ticket also fixes the following issue:
at various sites after updating sudo /etc/nsswitch.conf ended up with mode 600,
i.e. only readable by root, whereas the DNS libs need it to be world-readable.

That happens when root's umask is 077 and there is a sudo line present in the
file before sudo is updated.

That caused quite a bit of havoc.

Please ensure the next version also fixes that problem!
Comment 44 Maarten Litmaath 2012-08-14 10:03:51 EDT
Hi,
meanwhile I was informed of this update:

    http://rhn.redhat.com/errata/RHBA-2012-1160.html

--> https://bugzilla.redhat.com/show_bug.cgi?id=846974

--> https://bugzilla.redhat.com/show_bug.cgi?id=846631

The update presumably fixes all these issues in one go, thanks!
Comment 46 Gilles Detillieux 2012-09-19 23:36:41 EDT
I would strongly suggest you do away with the "mv" command in the post and postun scripts.  mv is just asking for trouble!  You got bit in July's update with a bad SELinux context (which mv carried over from a temporary file), and in the August update with a bad file mode (which mv carried over from a temporary file).  See a pattern here?  Using mv also would break any hard links on the target file, if any had been in place on the target system.  So instead, why not replace

   mv -f "$NSSWITCH_TMPFILE" %{nsswitch_path}

with

   cat "$NSSWITCH_TMPFILE" > %{nsswitch_path} && rm -f "$NSSWITCH_TMPFILE"

?

This way, you're overwriting the existing nsswitch.conf file right in place without mucking around with SELinux context, modes, extended attributes, ACLs, hard links, or ANYTHING else that the system owner might want to keep in place on that file.  This is even safer than using "sed -i" as Rob Foehl suggested in bug 846631.
Comment 49 Daniel Kopeček 2012-09-20 04:48:28 EDT
(In reply to comment #46)
Hi, you're right. The mv command was replaced with sed -i, however "sed -c -i" would be safer as it doesn't breaks hardlinks.
Comment 50 Miroslav Vadkerti 2012-09-20 06:27:08 EDT
We agreed with Dan that we would respin sudo one more time to add -c option to sed. Does everybody agree with this fix please?
Comment 51 Robert Scheck 2012-09-20 07:00:39 EDT
Miroslav, I would like to see the dependency to policycoreutils removed again
by using simply:

  [ -x /sbin/restorecon ] && /sbin/restorecon %{nsswitch_path}

instead of

  restorecon %{nsswitch_path}

Thanks!
Comment 52 Daniel Kopeček 2012-09-20 07:22:10 EDT
(In reply to comment #51)
The context specific dependency ensures correct ordering when installing the packages, so that the script aren't executed before installing the policycoreutils package.
Comment 53 Miroslav Vadkerti 2012-09-21 07:30:13 EDT
The fixed package had been respinned with fix from comment 49
Comment 57 errata-xmlrpc 2013-01-08 02:49:34 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-0112.html

Note You need to log in before you can comment on or make changes to this bug.