Bug 846974 - Postgresql fail to start on RHEL 5.8
Postgresql fail to start on RHEL 5.8
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: sudo (Show other bugs)
5.8
Unspecified Unspecified
urgent Severity urgent
: rc
: ---
Assigned To: Daniel Kopeček
Dalibor Pospíšil
: Regression, ZStream
Depends On: 846631
Blocks: 435010
  Show dependency treegraph
 
Reported: 2012-08-09 06:53 EDT by RHEL Product and Program Management
Modified: 2012-08-25 22:00 EDT (History)
16 users (show)

See Also:
Fixed In Version: sudo-1.7.2p1-14.el5_8.3
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-08-13 03:24:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
nsswitch.conf check script (335 bytes, application/x-shellscript)
2012-08-09 09:23 EDT, Daniel Kopeček
no flags Details

  None (edit)
Description RHEL Product and Program Management 2012-08-09 06:53:03 EDT
This bug has been copied from bug #846631 and has been proposed
to be backported to 5.8 z-stream (EUS).
Comment 6 Daniel Kopeček 2012-08-09 09:23:48 EDT
Created attachment 603256 [details]
nsswitch.conf check script
Comment 7 Dalibor Pospíšil 2012-08-09 13:05:22 EDT
If the package sudo-1.7.2p1-14.el5_8.3 is beeing uninstalled the context of /etc/nsswitch.conf is changed from system_u:object_r:etc_t:s0 to root:object_r:etc_t:s0. Next installation keeps root:object_r:etc_t:s0.
Why installation keeps user attributes while uninstall changes it?
Steps to reproduce:
1. remove sudo if present
2. recostrecon -F /etc/nsswitch.conf
3. ls -Z /etc/nsswitch.conf
-rw-r--r--  root root system_u:object_r:etc_t          /etc/nsswitch.conf
4. install sudo-1.7.2p1-14.el5_8.3
5. ls -Z /etc/nsswitch.conf
-rw-r--r--  root root system_u:object_r:etc_t          /etc/nsswitch.conf
6. remove sudo
7. ls -Z /etc/nsswitch.conf
-rw-r--r--  root root root:object_r:etc_t              /etc/nsswitch.conf
Comment 8 Daniel Walsh 2012-08-09 13:57:32 EDT
This is not a bug.  The difference is whether or not the file is being created freshly or copied into or mv'd.

If a new file is created it will get the SELinux User of the process that created it.  If it is written directly to or just mv'd the context will not change.

SELinux in RHEL and Fedora does not enforce anything based on the User component so this is not a bug.
Comment 9 Dalibor Pospíšil 2012-08-09 14:12:56 EDT
Ok than, I will write the test which will check only the :object_r:etc_t part.
Comment 10 Dalibor Pospíšil 2012-08-09 18:58:05 EDT
I found out that using little bit modified method as in el5_8.2 would not change even user attributes in selinux context. Just cat into file instead of mv:

a=`mktemp`
grep -v sudores /etc/nsswitch.conf > $a
cat $a >/etc/nsswitch.conf
rm -f $a
echo "sudoers:  files ldap" >>/etc/nsswitch.conf

This way the file in not recreated but just truncated and new content is written so no attributes are changed.
Comment 11 Karel Srot 2012-08-10 00:49:37 EDT
(In reply to comment #10)
> I found out that using little bit modified method as in el5_8.2 would not
> change even user attributes in selinux context. Just cat into file instead
> of mv:
> 
> a=`mktemp`
> grep -v sudores /etc/nsswitch.conf > $a
> cat $a >/etc/nsswitch.conf
> rm -f $a
> echo "sudoers:  files ldap" >>/etc/nsswitch.conf
> 
> This way the file in not recreated but just truncated and new content is
> written so no attributes are changed.

All of that is not necessary when using "sed -i" to update nsswitch.conf.
Comment 13 Rob Foehl 2012-08-10 11:24:18 EDT
The scripts proposed in bug 846764 solve this and other problems, and are complete with the exception of a test for the availability of restorecon (a condition mentioned in bug 818585).

The proposed change in bug 846631 for release as el5_8.3 still makes unnecessary modifications to /etc/nsswitch.conf.  Given the amount of damage -- which was in no way limited to Postgres -- done by the last few revisions of this package, is it too much to ask that this be reviewed/QAed by someone with a higher degree of familiarity with the shell?
Comment 15 errata-xmlrpc 2012-08-13 03:24:25 EDT
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-2012-1160.html

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