Description of problem: The logcheck program is running and generating an email with the following System Events =-=-=-=-=-=-= Jun 16 01:02:01 grandma setroubleshoot: SELinux is preventing /usr/bin/mktemp from create access on the directory logcheck.3vFhyg. For complete SELinux messages. run sealert -l 60671784-6eed-422d-bcca-82579fbbc373 When you run sealert you get the following errors before the main body: [root@grandma ~]# sealert -l 60671784-6eed-422d-bcca-82579fbbc373 WARNING: Policy would be downgraded from version 27 to 26. ** (setroubleshoot:29220): WARNING **: Trying to register gtype 'GMountMountFlags' as enum when in fact it is of type 'GFlags' ** (setroubleshoot:29220): WARNING **: Trying to register gtype 'GDriveStartFlags' as enum when in fact it is of type 'GFlags' ** (setroubleshoot:29220): WARNING **: Trying to register gtype 'GSocketMsgFlags' as enum when in fact it is of type 'GFlags' SELinux is preventing /usr/bin/mktemp from create access on the directory logcheck.aGtOH9. Version-Release number of selected component (if applicable): setroubleshoot.x86_64 3.1.11-1.fc17 How reproducible: everytime I run an sealert message Steps to Reproduce: 1.enter any sealert message 2. 3. Actual results: WARNING: Policy would be downgraded from version 27 to 26. ** (setroubleshoot:29220): WARNING **: Trying to register gtype 'GMountMountFlags' as enum when in fact it is of type 'GFlags' ** (setroubleshoot:29220): WARNING **: Trying to register gtype 'GDriveStartFlags' as enum when in fact it is of type 'GFlags' ** (setroubleshoot:29220): WARNING **: Trying to register gtype 'GSocketMsgFlags' as enum when in fact it is of type 'GFlags' SELinux is preventing /usr/bin/mktemp from create access on the directory logcheck.aGtOH9. ***** Plugin catchall (100. confidence) suggests *************************** If you believe that mktemp should be allowed create access on the logcheck.aGtOH9 directory by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep mktemp /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp WARNING: Policy would be downgraded from version 27 to 26. WARNING: Policy would be downgraded from version 27 to 26. Additional Information: Source Context system_u:system_r:logwatch_t:s0-s0:c0.c1023 Target Context system_u:object_r:user_tmp_t:s0 Target Objects logcheck.aGtOH9 [ dir ] Source mktemp Source Path /usr/bin/mktemp Port <Unknown> Host grandma.dbay.squires.id.au Source RPM Packages coreutils-8.15-6.fc17.x86_64 Target RPM Packages Policy RPM selinux-policy-3.10.0-128.fc17.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name grandma.dbay.squires.id.au Platform Linux grandma.dbay.squires.id.au 3.4.0-1.fc17.x86_64 #1 SMP Sun Jun 3 06:35:17 UTC 2012 x86_64 x86_64 Alert Count 7 First Seen Fri 15 Jun 2012 11:02:01 PM EST Last Seen Sat 16 Jun 2012 05:02:02 AM EST Local ID 60671784-6eed-422d-bcca-82579fbbc373 Raw Audit Messages type=AVC msg=audit(1339786922.292:983): avc: denied { create } for pid=28114 comm="mktemp" name="logcheck.aGtOH9" scontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023 tcontext=system_u:object_r:user_tmp_t:s0 tclass=dir type=SYSCALL msg=audit(1339786922.292:983): arch=x86_64 syscall=mkdir success=no exit=EACCES a0=da40b0 a1=1c0 a2=0 a3=d49bdb6fb677b899 items=0 ppid=28106 pid=28114 auid=992 uid=992 gid=989 euid=992 suid=992 fsuid=992 egid=989 sgid=989 fsgid=989 tty=(none) ses=94 comm=mktemp exe=/usr/bin/mktemp subj=system_u:system_r:logwatch_t:s0-s0:c0.c1023 key=(null) Hash: mktemp,logwatch_t,user_tmp_t,dir,create audit2allow #============= logwatch_t ============== allow logwatch_t user_tmp_t:dir create; audit2allow -R #============= logwatch_t ============== allow logwatch_t user_tmp_t:dir create; Expected results: SELinux is preventing /usr/bin/mktemp from create access on the directory logcheck.aGtOH9. ***** Plugin catchall (100. confidence) suggests *************************** If you believe that mktemp should be allowed create access on the logcheck.aGtOH9 directory by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep mktemp /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp WARNING: Policy would be downgraded from version 27 to 26. WARNING: Policy would be downgraded from version 27 to 26. Additional Information: Source Context system_u:system_r:logwatch_t:s0-s0:c0.c1023 Target Context system_u:object_r:user_tmp_t:s0 Target Objects logcheck.aGtOH9 [ dir ] Source mktemp Source Path /usr/bin/mktemp Port <Unknown> Host grandma.dbay.squires.id.au Source RPM Packages coreutils-8.15-6.fc17.x86_64 Target RPM Packages Policy RPM selinux-policy-3.10.0-128.fc17.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name grandma.dbay.squires.id.au Platform Linux grandma.dbay.squires.id.au 3.4.0-1.fc17.x86_64 #1 SMP Sun Jun 3 06:35:17 UTC 2012 x86_64 x86_64 Alert Count 7 First Seen Fri 15 Jun 2012 11:02:01 PM EST Last Seen Sat 16 Jun 2012 05:02:02 AM EST Local ID 60671784-6eed-422d-bcca-82579fbbc373 Raw Audit Messages type=AVC msg=audit(1339786922.292:983): avc: denied { create } for pid=28114 comm="mktemp" name="logcheck.aGtOH9" scontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023 tcontext=system_u:object_r:user_tmp_t:s0 tclass=dir type=SYSCALL msg=audit(1339786922.292:983): arch=x86_64 syscall=mkdir success=no exit=EACCES a0=da40b0 a1=1c0 a2=0 a3=d49bdb6fb677b899 items=0 ppid=28106 pid=28114 auid=992 uid=992 gid=989 euid=992 suid=992 fsuid=992 egid=989 sgid=989 fsgid=989 tty=(none) ses=94 comm=mktemp exe=/usr/bin/mktemp subj=system_u:system_r:logwatch_t:s0-s0:c0.c1023 key=(null) Hash: mktemp,logwatch_t,user_tmp_t,dir,create audit2allow #============= logwatch_t ============== allow logwatch_t user_tmp_t:dir create; audit2allow -R #============= logwatch_t ============== allow logwatch_t user_tmp_t:dir create; Additional info: There is also a bug in the logcheck rpm. When I installed it, the selinux policy prevents usr/bin/mktemp from creating directories in /tmp After running the multipule alert messages I have generated the following policy module logcheck 1.0; require { type user_tmp_t; type logwatch_t; class dir { write create add_name }; } #============= logwatch_t ============== allow logwatch_t user_tmp_t:dir create; #!!!! This avc is allowed in the current policy allow logwatch_t user_tmp_t:dir { write add_name };
Policy will be downgraded will be fixed when the 3.5 kernel arrives. This is telling you that you have a newer tool chain then the kernel supports. The other warnings come from import gtk
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.