Description of problem: Thunderbird has become unstable since the selinux-policy update yesterday. It crashed a couple times. SELinux has denied /sbin/ldconfig access to potentially mislabeled file(s) (/home/fandrei/.thunderbird/u1avjcki.default/.parentlock). This means that SELinux will not allow /sbin/ldconfig to use these files. It is common for users to edit files in their home directory or tmp directories and then move (mv) them to system directories. The problem is that the files end up with the wrong file context which confined applications are not allowed to access. avc: denied { read, write } for comm="ldconfig" dev=sda3 egid=500 euid=500 exe="/sbin/ldconfig" exit=0 fsgid=500 fsuid=500 gid=500 items=0 name="xine-user.msf" path="/home/fandrei/.thunderbird/u1avjcki.default/.parentlock" pid=5019 scontext=user_u:system_r:ldconfig_t:s0 sgid=500 subj=user_u:system_r:ldconfig_t:s0 suid=500 tclass=file tcontext=user_u:object_r:user_home_t:s0 tty=(none) uid=500 [fandrei@valar ~]$ ls -Z /home/fandrei/.thunderbird/u1avjcki.default/.parentlock -rw-rw-r-- fandrei fandrei user_u:object_r:user_home_t /home/fandrei/.thunderbird/u1avjcki.default/.parentlock Version-Release number of selected component (if applicable): selinux-policy-2.6.4-21.fc7 How reproducible: Somewhat reproducible Steps to Reproduce: 1. run Thunderbird 2. wait 3. Actual results: Thunderbird goes kaboom Expected results: duh Additional info:
Why would ldconfig be trying to read the files .parentlock? I believe this is a leaked file descriptor. Some where thunderbird is execing ldconfig. ldconfig is looking at all the open file descriptors and checking the access, this generates this avc, but I am pretty sure should not cause any instability in thunderbird.
Thunderbird doesn't call ldconfig anywhere as nothing it intalls ought to be in a directory which ldconfig knows about it.
At this point, we're going to only be taking security fixes and major stability fixes into this release of Fedora. However, we still want to ensure the bug is fixed in the next version. We'd appreciate if you could test with the latest version of Thunderbird (2.0.0.12) now available for your distribution and provide feedback as to whether the problem still exists so we can file a ticket upstream as soon as possible.
Since there are insufficient details provided in this report for us to investigate the issue further, and we have not received feedback to the information we have requested above, we will assume the problem was not reproducible, or has been fixed in one of the updates we have released for the reporter's distribution. Users who have experienced this problem are encouraged to upgrade to the latest update of their distribution, and if this issue turns out to still be reproducible in the latest update, please reopen this bug with additional information. Closing as INSUFFICIENT_DATA.