ldconfig + SELinux = symlink slaughter

[Dave Mack]

OK, this is getting mildly annoying. With the current Rawhide tree (and 
for about the last week) I've been running into a problem when I "yum 
update" with SELinux in enforcing mode: the reboot which follows fails 
because most of the symlinks to shared libraries in /lib have 
evaporated. The culprit is ldconfig, which is being run during the yum 
update after library changes.

Reproduce by:

# ls -l /lib/libtermcap.so.2*

lrwxrwxrwx   1 root root 19 Dec 11 09:17   /lib/termcap.so.2 -> 
libtermcap.so.2.0.8
-rwxr-xr-x   1 root root 12952 Jun 15 17:34 /lib/libtermcap.so.2.0.8

# setenforce 1
# ldconfig

<many lines of complaint about "Input file /lib/<something>.so not
found">

# ls -l /lib/libtermcap.so.2*

ls: error while loading shared libraries: libacl.so.1: cannot open 
shared object file: No such file or directory

# setenforce 0

# ldconfig

<no errors>

Now everything is back to normal.

Is anyone else able to reproduce this or is it just me? Known bug?

Dave

[Dave Mack]

Please disregard the previous message. Running "fixfiles relabel" 
resolved the problem.

Dave

Dave Mack wrote:

>  OK, this is getting mildly annoying. With the current Rawhide tree 
>  (and for about the last week) I've been running into a problem when I 
>  "yum update" with SELinux in enforcing mode: the reboot which follows 
>  fails because most of the symlinks to shared libraries in /lib have 
>  evaporated. The culprit is ldconfig, which is being run during the yum 
>  update after library changes.
>
>  Reproduce by:
>
>  # ls -l /lib/libtermcap.so.2*
>
>  lrwxrwxrwx   1 root root 19 Dec 11 09:17   /lib/termcap.so.2 -> 
>  libtermcap.so.2.0.8
>  -rwxr-xr-x   1 root root 12952 Jun 15 17:34 /lib/libtermcap.so.2.0.8
>
>  # setenforce 1
>  # ldconfig
>
>  <many lines of complaint about "Input file /lib/<something>.so not 
>  found">
>
>  # ls -l /lib/libtermcap.so.2*
>
>  ls: error while loading shared libraries: libacl.so.1: cannot open 
>  shared object file: No such file or directory
>
>  # setenforce 0
>
>  # ldconfig
>
>  <no errors>
>
>  Now everything is back to normal.
>
>  Is anyone else able to reproduce this or is it just me? Known bug?
>
>  Dave
>

[Richard Hally]

Dave Mack wrote:

>  OK, this is getting mildly annoying. With the current Rawhide tree 
>  (and for about the last week) I've been running into a problem when I 
>  "yum update" with SELinux in enforcing mode: the reboot which follows 
>  fails because most of the symlinks to shared libraries in /lib have 
>  evaporated. The culprit is ldconfig, which is being run during the yum 
>  update after library changes.
>
>  Reproduce by:
>
>  # ls -l /lib/libtermcap.so.2*
>
>  lrwxrwxrwx   1 root root 19 Dec 11 09:17   /lib/termcap.so.2 -> 
>  libtermcap.so.2.0.8
>  -rwxr-xr-x   1 root root 12952 Jun 15 17:34 /lib/libtermcap.so.2.0.8
>
>  # setenforce 1
>  # ldconfig
>
>  <many lines of complaint about "Input file /lib/<something>.so not 
>  found">
>
>  # ls -l /lib/libtermcap.so.2*
>
>  ls: error while loading shared libraries: libacl.so.1: cannot open 
>  shared object file: No such file or directory
>
>  # setenforce 0
>
>  # ldconfig
>
>  <no errors>
>
>  Now everything is back to normal.
>
>  Is anyone else able to reproduce this or is it just me? Known bug?
>
>  Dave
>  
This problem has been fixed. Make sure that you have the latest (from 
rawhide) rpm package and the latest libselinux package.
HTH
Richard Hally

[Stephen Smalley]

On Sat, 2004-12-11 at 12:33, Dave Mack wrote:
>  OK, this is getting mildly annoying. With the current Rawhide tree
> (and 
>  for about the last week) I've been running into a problem when I "yum 
>  update" with SELinux in enforcing mode: the reboot which follows fails 
>  because most of the symlinks to shared libraries in /lib have 
>  evaporated. The culprit is ldconfig, which is being run during the yum 
>  update after library changes.
>  
>  Reproduce by:
>  
>  # ls -l /lib/libtermcap.so.2*
>  
>  lrwxrwxrwx   1 root root 19 Dec 11 09:17   /lib/termcap.so.2 -> 
>  libtermcap.so.2.0.8
>  -rwxr-xr-x   1 root root 12952 Jun 15 17:34 /lib/libtermcap.so.2.0.8
>  
>  # setenforce 1
>  # ldconfig
>  
>  <many lines of complaint about "Input file /lib/<something>.so not
> found">
>  
>  # ls -l /lib/libtermcap.so.2*
>  
>  ls: error while loading shared libraries: libacl.so.1: cannot open 
>  shared object file: No such file or directory
>  
>  # setenforce 0
>  
>  # ldconfig
>  
>  <no errors>
>  
>  Now everything is back to normal.
>  
>  Is anyone else able to reproduce this or is it just me? Known bug? 
There have been reports of shared objects becoming mislabeled over time,
but the precise cause is not yet known - likely prelink or rpm or a
combination due to an interleaving of an update and a prelink run.  That
could be the source of your problem with ldconfig.  Questions:
1) Are there any errors in your /var/log/prelink.log file of the form
'Could not get security context' or 'Could not set security context'?
2) Have you run with SELinux disabled at any time, and then failed to
fixfiles relabel when re-enabling SELinux?  That could leave such files
unlabeled due to updates or prelink runs while SELinux was disabled.
3) Are there any errors in /var/log/messages with the function name
"post_create" in them?

--
Stephen Smalley <sds(a)epoch.ncsc.mil&gt;
National Security Agency

[Dave Mack]

Stephen,

Thanks for taking an interest in this problem. Answers inline.

Stephen Smalley wrote:

> On Sat, 2004-12-11 at 12:33, Dave Mack wrote:
>   
>
> >OK, this is getting mildly annoying. With the current Rawhide tree (and 
> >for about the last week) I've been running into a problem when I "yum 
> >update" with SELinux in enforcing mode: the reboot which follows fails 
> >because most of the symlinks to shared libraries in /lib have 
> >evaporated. The culprit is ldconfig, which is being run during the yum 
> >update after library changes.
> >
> >Reproduce by:
> >
> ># ls -l /lib/libtermcap.so.2*
> >
> >lrwxrwxrwx   1 root root 19 Dec 11 09:17   /lib/termcap.so.2 -> 
> >libtermcap.so.2.0.8
> >-rwxr-xr-x   1 root root 12952 Jun 15 17:34 /lib/libtermcap.so.2.0.8
> >
> ># setenforce 1
> ># ldconfig
> >
> ><many lines of complaint about "Input file /lib/<something>.so not
> found">
> >
> ># ls -l /lib/libtermcap.so.2*
> >
> >ls: error while loading shared libraries: libacl.so.1: cannot open 
> >shared object file: No such file or directory
> >
> ># setenforce 0
> >
> ># ldconfig
> >
> ><no errors>
> >
> >Now everything is back to normal.
> >
> >Is anyone else able to reproduce this or is it just me? Known bug?
> >    
> >
>
> There have been reports of shared objects becoming mislabeled over time,
> but the precise cause is not yet known - likely prelink or rpm or a
> combination due to an interleaving of an update and a prelink run.  That
> could be the source of your problem with ldconfig.  Questions:
> 1) Are there any errors in your /var/log/prelink.log file of the form
> 'Could not get security context' or 'Could not set security context'?
>   
>  
There aren't any messages referring to "security context" in prelink.log.

> 2) Have you run with SELinux disabled at any time, and then failed to
> fixfiles relabel when re-enabling SELinux?  That could leave such files
> unlabeled due to updates or prelink runs while SELinux was disabled.
>   
>  
This would certainly be my guess as the cause. As I mentioned in a 
subsequent message to the list, running "fixfiles relabel" solved the 
problem with ldconfig in enforcing mode.

> 3) Are there any errors in /var/log/messages with the function name
> "post_create" in them?
>
>   
>  
No.

> --
> Stephen Smalley <sds(a)epoch.ncsc.mil&gt;
> National Security Agency
>
>   
>

[Stephen Smalley]

On Mon, 2004-12-13 at 14:08, Dave Mack wrote:
>  This would certainly be my guess as the cause. As I mentioned in a 
>  subsequent message to the list, running "fixfiles relabel" solved the 
>  problem with ldconfig in enforcing mode. 
Ok; if you encounter the problem again while running with SELinux
enabled continuously (or at least having run fixfiles relabel after each
time you've run with SELinux disabled), then please report it.

-- 
Stephen Smalley <sds(a)epoch.ncsc.mil&gt;
National Security Agency