Bug 621842

On my system (exactly the same package revisions as above), the error was generated during my normal nightly run of "recollindex" from package 
recoll-1.13.04-1.fc13.x86_64
This error has not occurred previously.

This also happens on F14

No change in behavior after the upgrade to selinux-policy-3-7.19-44.fc13 on kernel 2.6.34.2-34.fc13.x86_64.

I started seing this after installation of selinux-policy-3.7.19-44.fc13 - it didn't occur while I was using selinux-policy-3.7.19-41.fc13. Strange.

Created attachment 437813 [details]
Still happens with selinux-policy-3.7.19-44.fc13

error ouput attached from selinux-policy-3.7.19-44.fc13

Created attachment 438313 [details]
print-screen

Same here (JST) happened today, see attachment (jpg). I have an error msg at the bottom of the window, on the left: "Error while checking policy version". How do I fix that?

PS: I am not familiar with the bugzilla redhat, in the event my attachment is not proper, please instruct how to include a print screen in a comment, thanks.

This happens every time prelink kicks in on my F13 box.

This morning was the first I've seen this AVC denial. I've been running selinux-policy-3.7.19.44.fc13 since it came out on updates-testing. I was choosing packages to install with Yum Extender, and using bash in a terminal to get information on installed packages (rpm -q, yum info). I did not notice the AVC denial when it occurred; I saw the setroubleshoot applet about half an hour later.

I also had the "Error while checking policy version" message in the browser, maybe because both yumex and yum info were running?

The message "Error while checking policy version" have a bug report https://bugzilla.redhat.com/show_bug.cgi?id=621709.

Summary:

SELinux is preventing /bin/bash access to a leaked /root file descriptor.

Detailed Description:

[prelink has a permissive type (prelink_cron_system_t). This access was not
denied.]

SELinux denied access requested by the prelink command. It looks like this is
either a leaked descriptor or prelink output was redirected to a file it is not
allowed to access. Leaks usually can be ignored since SELinux is just closing
the leak and reporting the error. The application does not use the descriptor,
so it will run properly. If this is a redirection, you will not get output in
the /root. You should generate a bugzilla on selinux-policy, and it will get
routed to the appropriate package. You can safely ignore this avc.

Allowing Access:

You can generate a local policy module to allow this access - see FAQ
(http://docs.fedoraproject.org/selinux-faq-fc5/#id2961385)

Additional Information:

Source Context                system_u:system_r:prelink_cron_system_t:s0-s0:c0.c
                              1023
Target Context                system_u:object_r:admin_home_t:s0
Target Objects                /root [ dir ]
Source                        prelink
Source Path                   /bin/bash
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           bash-4.1.7-1.fc13
Target RPM Packages           filesystem-2.4.31-1.fc13
Policy RPM                    selinux-policy-3.7.19-44.fc13
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Plugin Name                   leaks
Host Name                     (removed)
Platform                      Linux (removed) 2.6.33.6-147.2.4.fc13.i686.PAE
                              #1 SMP Fri Jul 23 17:21:06 UTC 2010 i686 i686
Alert Count                   1
First Seen                    Wed 11 Aug 2010 03:14:21 PM PDT
Last Seen                     Wed 11 Aug 2010 03:14:21 PM PDT
Local ID                      d2a65adc-da30-4b8d-b137-903018f36c3a
Line Numbers                  

Raw Audit Messages            

node=(removed) type=AVC msg=audit(1281564861.153:23098): avc:  denied  { read } for  pid=3217 comm="prelink" path="/root" dev=dm-0 ino=130820 scontext=system_u:system_r:prelink_cron_system_t:s0-s0:c0.c1023 tcontext=system_u:object_r:admin_home_t:s0 tclass=dir

node=(removed) type=SYSCALL msg=audit(1281564861.153:23098): arch=40000003 syscall=11 success=yes exit=0 a0=a03cc98 a1=a03cb20 a2=a039b78 a3=a03cb20 items=0 ppid=2499 pid=3217 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=9 comm="prelink" exe="/bin/bash" subj=system_u:system_r:prelink_cron_system_t:s0-s0:c0.c1023 key=(null)

The message "Error while checking policy version" is due to corrupted yum metadata. A "yum clean metadata" fix the error message (more detais in https://bugzilla.redhat.com/show_bug.cgi?id=621709). 

I can reproduce the bash/prelink error. I run
# /etc/cron.daily/prelink
and
# run-parts /etc/cron.daily

and nothing happens... Someone have a idea to reproduce that bug?

*** Bug 623755 has been marked as a duplicate of this bug. ***

Miroslav, I added

 userdom_dontaudit_list_admin_dir(prelink_cron_system_t)

I am thinking this is a bug in cron, but I am not sure.  If other confined domains start trying to list /root I will pass it to them.

I think you might be on to something Mr. Walsh. It went off on me yesterday and I thought it was flash or something with firefox but I just checked my logs and it was cron starting up.

I added it to selinux-policy-3.7.19-47.fc13. But it really looks like cronnie is leaking a file descriptor.

It's happening since cronie-1.4.5-1.fc13.i686.
Did cronie change the cwd by chance?

Yup just confirmed. Cron just started and I got the alert right before it terminated normally. It's cron.

selinux-policy-3.7.19-47.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/selinux-policy-3.7.19-47.fc13

(In reply to comment #17)
> Yup just confirmed. Cron just started and I got the alert right before it
> terminated normally. It's cron.    

cron or anacron. I have been monitoring this for over a week now and it always happens before anacron finishes up (it does my automated backup and like also runs system jobs like prelink, etc. -- I have not changed the default settings in anacrontab/crontab, so the random delay is unpredictable, but that is it).

*** Bug 623488 has been marked as a duplicate of this bug. ***

*** Bug 622185 has been marked as a duplicate of this bug. ***

Since everyone agrees the problem is cronie-side...

*** This bug has been marked as a duplicate of bug 623908 ***

selinux-policy-3.7.19-47.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

(In reply to comment #23)
> selinux-policy-3.7.19-47.fc13 has been pushed to the Fedora 13 stable
> repository.  If problems still persist, please make note of it in this bug
> report.

But I can't to update my system, the program's update allways shows the message to run the "yum-complete-transaction", but when I run, show the following errors:

Warning: the RPMDB whas changed from outside the yum.
** Found 1 pre-existing rpmdb problem(s), 'yum check' output follows:
libdvdcss-1.2.10-1.x86_64 é uma duplicação do libdvdcss-1.2.9-5.fc10.i386
Traceback (most recent call last):
  File "/usr/sbin/yum-complete-transaction", line 256, in <module>
    util = YumCompleteTransaction()
  File "/usr/sbin/yum-complete-transaction", line 118, in __init__
    self.main()
  File "/usr/sbin/yum-complete-transaction", line 239, in main
    if self.doUtilTransaction() == 0:
  File "/usr/share/yum-cli/utils.py", line 339, in doUtilTransaction
    return_code = self.doTransaction()
  File "/usr/share/yum-cli/cli.py", line 544, in doTransaction
    resultobject = self.runTransaction(cb=cb)
  File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 1334, in runTransaction
    self.skipped_packages, rpmdb_problems, cmdline)
  File "/usr/lib/python2.6/site-packages/yum/history.py", line 500, in beg
    self._trans_rpmdb_problem(problem)
  File "/usr/lib/python2.6/site-packages/yum/history.py", line 433, in _trans_rpmdb_problem
    to_unicode(str(problem))))
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 26: ordinal not in range(128)

bruno,
the problem you're seeing is an unrelated bug.

If you can please update to yum for f13, that should solve that problem.

Also - you can step around the problem temporarily by running yum like:

LANG=C yum update

(In reply to comment #25)
> bruno,
> the problem you're seeing is an unrelated bug.
> 
> If you can please update to yum for f13, that should solve that problem.
> 
> Also - you can step around the problem temporarily by running yum like:
> 
> LANG=C yum update

It's works, thank you