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
/etc directory was mislabelled on more machines and an existing dontaudit rule prevented audit daemon from writing the AVC into audit.log.
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 }; #
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.
# 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"" #
# 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 #
Sudo should be doing a restorecon after the move at the least.
*** Bug 840529 has been marked as a duplicate of this bug. ***
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.
This will be fixed in version sudo-1.7.2p1-15.el5
*** Bug 841195 has been marked as a duplicate of this bug. ***
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.
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".
*** Bug 841484 has been marked as a duplicate of this bug. ***
*** Bug 841752 has been marked as a duplicate of this bug. ***
*** Bug 842384 has been marked as a duplicate of this bug. ***
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.
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.
easy work-around is command on all el5.8 machines: restorecon /etc/nsswitch.conf
(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.
(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/
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.)
(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"
(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.
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 :-(
(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.
Soon means in Red Hat terms another 14 days :(
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.
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!
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!
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.
(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.
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?
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!
(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.
The fixed package had been respinned with fix from comment 49
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