Bug 143868 - ldconfig: Cannot lstat/stat ...:Permission denied
ldconfig: Cannot lstat/stat ...:Permission denied
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
3
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Daniel Walsh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-30 09:08 EST by Matthias Haag
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-01-04 12:07:27 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
"ldconfig -v" run in normal environment" (4.46 KB, text/plain)
2005-01-02 15:05 EST, Matthias Haag
no flags Details
dmesg output after "ldconfig -v" run in normal environment (782 bytes, text/plain)
2005-01-02 15:07 EST, Matthias Haag
no flags Details
"ldconfig -v" in rescue system (32.69 KB, text/plain)
2005-01-02 15:09 EST, Matthias Haag
no flags Details

  None (edit)
Description Matthias Haag 2004-12-30 09:08:32 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.7.5)
Gecko/20041111 Firefox/1.0

Description of problem:
Bad: The ldconfig command doesn't run any more. I always get these errors:
cspc002:/usr/lib/test root$ll
total 152
-rwxrwxrwx  1 root root 152688 Dec 23 18:32 libksvgrendererlibart.so
cspc002:/usr/lib/test root$chmod 777 .
cspc002:/usr/lib/test root$ldconfig -nvN /usr/lib/test
/usr/lib/test:
ldconfig: Cannot lstat /usr/lib/test/libksvgrendererlibart.so:
Permission denied

I get the error for almost all libraries!

Good: If I start the rescue system, do a chroot and run a ldconfig
everything is ok.

Version-Release number of selected component (if applicable):
glibc-2.3.4-2.fc3

How reproducible:
Always

Steps to Reproduce:
I just run ldconfig.

Actual Results:  I cannot even do an ls because the system doesn't
find libacl.so anymore. Seems like the library cache gets empty
because of the permission denied errors. System is unusable!

Expected Results:  The library cache should be updated.
Comment 1 Sitsofe Wheeler 2004-12-30 12:46:58 EST
Do you have any selinux error in dmesg?
Comment 2 Matthias Haag 2004-12-31 09:32:19 EST
Yes. See the output here:
cspc002:/root root$ldconfig -nvN /usr/lib/test
/usr/lib/test:
ldconfig: Cannot lstat /usr/lib/test/libksvgrendererlibart.so: Permission denied

cspc002:/root root$dmesg|tail
Bluetooth: L2CAP socket layer initialized
Bluetooth: RFCOMM ver 1.3
Bluetooth: RFCOMM socket layer initialized
Bluetooth: RFCOMM TTY layer initialized
eth0: no IPv6 routers present
parport0: PC-style at 0x3bc [PCSPP,TRISTATE]
lp0: using parport0 (polling).
lp0: console ready
Non-volatile memory driver v1.2
audit(1104487781.430:0): avc:  denied  { getattr } for  pid=3449
exe=/sbin/ldconfig path=/usr/lib/test/libksvgrendererlibart.so dev=dm-0
ino=8704394 scontext=root:system_r:ldconfig_t tcontext=root:object_r:lib_t
tclass=file
Comment 3 Jakub Jelinek 2004-12-31 15:39:38 EST
That is not a ldconfig nor glibc bug.
Shared libraries that don't have *:shlib_t SELinux context can't be read by ldconfig nor loaded by any SELinux confined program as shared library.
/usr/lib/test/ is not a standard library path for shared libraries listed in
/etc/selinux/targeted/contexts/files/file_contexts, so restorecon
will not work, but chcon root:object_r:shlib_t /usr/lib/test/libksvgrendererlibart.so should work.
Comment 4 Matthias Haag 2005-01-02 14:35:56 EST
The error doesn't only occur if I do it on a non-standard path. I get same
errors on standard paths like /lib or /usr/lib:
audit(1104694276.504:0): avc:  denied  { search } for  pid=3913
exe=/sbin/ldconfig name=lib dev=dm-0 ino=20971652
scontext=root:system_r:ldconfig_t tcontext=root:object_r:shlib_t tclass=dir
audit(1104694276.505:0): avc:  denied  { search } for  pid=3913
exe=/sbin/ldconfig name=lib dev=dm-0 ino=20971652
scontext=root:system_r:ldconfig_t tcontext=root:object_r:shlib_t tclass=dir
audit(1104694276.505:0): avc:  denied  { getattr } for  pid=3913
exe=/sbin/ldconfig path=/usr/lib dev=dm-0 ino=20971652
scontext=root:system_r:ldconfig_t tcontext=root:object_r:shlib_t tclass=dir
audit(1104694287.646:0): avc:  denied  { search } for  pid=3916
exe=/sbin/ldconfig name=lib dev=dm-0 ino=20971652
scontext=root:system_r:ldconfig_t tcontext=root:object_r:shlib_t tclass=dir
audit(1104694287.646:0): avc:  denied  { search } for  pid=3916
exe=/sbin/ldconfig name=lib dev=dm-0 ino=20971652
scontext=root:system_r:ldconfig_t tcontext=root:object_r:shlib_t tclass=dir
audit(1104694287.646:0): avc:  denied  { getattr } for  pid=3916
exe=/sbin/ldconfig path=/usr/lib dev=dm-0 ino=20971652
scontext=root:system_r:ldconfig_t tcontext=root:object_r:shlib_t tclass=dir
audit(1104694287.663:0): avc:  denied  { getattr } for  pid=3916
exe=/sbin/ldconfig path=/lib/libselinux.so.1 dev=dm-0 ino=4442592
scontext=root:system_r:ldconfig_t tcontext=root:object_r:lib_t tclass=file
audit(1104694305.623:0): avc:  denied  { search } for  pid=3922
exe=/sbin/ldconfig name=lib dev=dm-0 ino=20971652
scontext=root:system_r:ldconfig_t tcontext=root:object_r:shlib_t tclass=dir
audit(1104694305.623:0): avc:  denied  { search } for  pid=3922
exe=/sbin/ldconfig name=lib dev=dm-0 ino=20971652
scontext=root:system_r:ldconfig_t tcontext=root:object_r:shlib_t tclass=dir
audit(1104694305.623:0): avc:  denied  { getattr } for  pid=3922
exe=/sbin/ldconfig path=/usr/lib dev=dm-0 ino=20971652
scontext=root:system_r:ldconfig_t tcontext=root:object_r:shlib_t tclass=dir
audit(1104694305.640:0): avc:  denied  { getattr } for  pid=3922
exe=/sbin/ldconfig path=/lib/libselinux.so.1 dev=dm-0 ino=4442592
scontext=root:system_r:ldconfig_t tcontext=root:object_r:lib_t tclass=file
audit(1104694309.531:0): avc:  denied  { search } for  pid=3925
exe=/sbin/ldconfig name=lib dev=dm-0 ino=20971652
scontext=root:system_r:ldconfig_t tcontext=root:object_r:shlib_t tclass=dir
audit(1104694309.531:0): avc:  denied  { search } for  pid=3925
exe=/sbin/ldconfig name=lib dev=dm-0 ino=20971652
scontext=root:system_r:ldconfig_t tcontext=root:object_r:shlib_t tclass=dir
audit(1104694309.531:0): avc:  denied  { getattr } for  pid=3925
exe=/sbin/ldconfig path=/usr/lib dev=dm-0 ino=20971652
scontext=root:system_r:ldconfig_t tcontext=root:object_r:shlib_t tclass=dir
audit(1104694309.546:0): avc:  denied  { getattr } for  pid=3925
exe=/sbin/ldconfig path=/lib/libselinux.so.1 dev=dm-0 ino=4442592
scontext=root:system_r:ldconfig_t tcontext=root:object_r:lib_t tclass=file
Comment 5 Matthias Haag 2005-01-02 15:05:30 EST
Created attachment 109238 [details]
"ldconfig -v" run in normal environment"
Comment 6 Matthias Haag 2005-01-02 15:07:11 EST
Created attachment 109239 [details]
dmesg output after "ldconfig -v" run in normal environment
Comment 7 Matthias Haag 2005-01-02 15:09:30 EST
Created attachment 109240 [details]
"ldconfig -v" in rescue system
Comment 8 Gianluca Amato 2005-01-03 11:13:16 EST
I have the same problem when I install packages with apt-get. After
installation/upgrade of a package, ldconfig cannot access the shared
libraries in the package, since they have the wrong security context.
It seems there is a bug in APT (see
http://distro.conectiva.com.br/pipermail/apt-rpm/2004-June/002413.html)
Comment 9 Daniel Walsh 2005-01-03 13:17:44 EST
What directory is marked shlib_t?

I have added ability to read lib_t which should allow ldconfig_t to
function but we will still have problems if a protected daemon tries
to read a shared library marked lib_t.

Apt-rpm is not shipped with Fedora, so I don't work with it.  Seems
that it must be running an older version of rpm without SELinux support.

Dan
Comment 10 Matthias Haag 2005-01-04 10:18:11 EST
Hi Dan,

how do I get the information you need? I'm not so firm with the
SELinux things.

Matze
Comment 11 Daniel Walsh 2005-01-04 10:58:00 EST
Matze, 

To fix the problem you can just do a 
touch /.autorelabel 
reboot

Which will fix the labels on your system.

To find it you could try
find / --context system_u:object_r:shlib_t -type d 
And if that fails
find / --context root:object_r:shlib_t -type d 
Comment 12 Matthias Haag 2005-01-04 11:50:55 EST
Hi Dan,

the autorelabel worked! Now ldconfig now runs normally again. In my
opinion we can close this bug. Seems like somehow the contexts of some
directories has been changed. But in fact I don't know how. The two
find commands don't produce output (only errors for the /proc filesystem).

Matze

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