Dear folks,
The title has been reported as NOT A BUG, but it is annoying :( without doing anything but logging in, the setroubleshooter kicks in and displays the message. I have tried numerous times to report it, but it came back empty. Then I click enough times and see that it is there, but it is NOT A BUG :(, I don't agree but can't do shite.
--- Running report_Bugzilla --- Logging into Bugzilla at https://bugzilla.redhat.com Checking for duplicates Bug is already reported: 812100 Logging out Status: CLOSED NOTABUG https://bugzilla.redhat.com/show_bug.cgi?id=812100
--- Running report_Bugzilla --- This problem was already reported to Bugzilla (see 'https://bugzilla.redhat.com/show_bug.cgi?id=812100'). Do you still want to create a new bug? NO
SELinux is preventing dmesg from 'read' accesses on the file /etc/ld.so.cache.
***** Plugin restorecon (94.8 confidence) suggests *************************
If you want to fix the label. /etc/ld.so.cache default label should be ld_so_cache_t. Then you can run restorecon. Do # /sbin/restorecon -v /etc/ld.so.cache
***** Plugin catchall_labels (5.21 confidence) suggests ********************
If you want to allow dmesg to have read access on the ld.so.cache file Then you need to change the label on /etc/ld.so.cache Do # semanage fcontext -a -t FILE_TYPE '/etc/ld.so.cache' where FILE_TYPE is one of the following: cpu_online_t, afs_cache_t, abrt_helper_exec_t, textrel_shlib_t, rpm_script_tmp_t, user_cron_spool_t, puppet_tmp_t, ld_so_cache_t, abrt_var_run_t, udev_var_run_t, sysctl_kernel_t, abrt_var_run_t, sysctl_crypto_t, locale_t, dmesg_t, proc_t, sysfs_t, dmesg_exec_t, abrt_t, lib_t, ld_so_t. Then execute: restorecon -v '/etc/ld.so.cache'
***** Plugin catchall (1.44 confidence) suggests ***************************
If you believe that dmesg should be allowed read access on the ld.so.cache file 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 dmesg /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp
Additional Information: Source Context system_u:system_r:dmesg_t:s0 Target Context unconfined_u:object_r:etc_t:s0 Target Objects /etc/ld.so.cache [ file ] Source dmesg Source Path dmesg Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages glibc-2.15-32.fc17.i686 Policy RPM selinux-policy-3.10.0-116.fc17.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux acer-aspire-1 3.3.2-1.fc17.i686 #1 SMP Fri Apr 13 21:06:40 UTC 2012 i686 i686 Alert Count 1 First Seen Thu 19 Apr 2012 09:30:20 PM CDT Last Seen Thu 19 Apr 2012 09:30:20 PM CDT Local ID db50d35a-1a8c-4e53-a4ae-98765dcb81db
Raw Audit Messages type=AVC msg=audit(1334889020.147:6): avc: denied { read } for pid=633 comm="dmesg" name="ld.so.cache" dev="dm-1" ino=54745 scontext=system_u:system_r:dmesg_t:s0 tcontext=unconfined_u:object_r:etc_t:s0 tclass=file
Hash: dmesg,dmesg_t,etc_t,file,read
audit2allowunable to open /sys/fs/selinux/policy: Permission denied
audit2allow -Runable to open /sys/fs/selinux/policy: Permission denied
What do I do, please advice. I am getting annoyed, frustrated and I would hate to kill off selinux, because I actually like it, but the NOT A BUG does bother me. I have had the past three or four days dealing with this, and now I am finally doing something about it :(
Thanks for listening.
Regards,
Antonio
On 04/20/2012 04:42 AM, Antonio Olivares wrote:
Dear folks,
The title has been reported as NOT A BUG, but it is annoying :( without doing anything but logging in, the setroubleshooter kicks in and displays the message. I have tried numerous times to report it, but it came back empty. Then I click enough times and see that it is there, but it is NOT A BUG :(, I don't agree but can't do shite.
--- Running report_Bugzilla --- Logging into Bugzilla at https://bugzilla.redhat.com Checking for duplicates Bug is already reported: 812100 Logging out Status: CLOSED NOTABUG https://bugzilla.redhat.com/show_bug.cgi?id=812100
--- Running report_Bugzilla --- This problem was already reported to Bugzilla (see 'https://bugzilla.redhat.com/show_bug.cgi?id=812100'). Do you still want to create a new bug? NO
SELinux is preventing dmesg from 'read' accesses on the file /etc/ld.so.cache.
***** Plugin restorecon (94.8 confidence) suggests *************************
If you want to fix the label. /etc/ld.so.cache default label should be ld_so_cache_t. Then you can run restorecon. Do # /sbin/restorecon -v /etc/ld.so.cache
***** Plugin catchall_labels (5.21 confidence) suggests ********************
If you want to allow dmesg to have read access on the ld.so.cache file Then you need to change the label on /etc/ld.so.cache Do # semanage fcontext -a -t FILE_TYPE '/etc/ld.so.cache' where FILE_TYPE is one of the following: cpu_online_t, afs_cache_t, abrt_helper_exec_t, textrel_shlib_t, rpm_script_tmp_t, user_cron_spool_t, puppet_tmp_t, ld_so_cache_t, abrt_var_run_t, udev_var_run_t, sysctl_kernel_t, abrt_var_run_t, sysctl_crypto_t, locale_t, dmesg_t, proc_t, sysfs_t, dmesg_exec_t, abrt_t, lib_t, ld_so_t. Then execute: restorecon -v '/etc/ld.so.cache'
***** Plugin catchall (1.44 confidence) suggests ***************************
If you believe that dmesg should be allowed read access on the ld.so.cache file 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 dmesg /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp
Additional Information: Source Context system_u:system_r:dmesg_t:s0 Target Context unconfined_u:object_r:etc_t:s0 Target Objects /etc/ld.so.cache [ file ] Source dmesg Source Path dmesg Port<Unknown> Host (removed) Source RPM Packages Target RPM Packages glibc-2.15-32.fc17.i686 Policy RPM selinux-policy-3.10.0-116.fc17.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux acer-aspire-1 3.3.2-1.fc17.i686 #1 SMP Fri Apr 13 21:06:40 UTC 2012 i686 i686 Alert Count 1 First Seen Thu 19 Apr 2012 09:30:20 PM CDT Last Seen Thu 19 Apr 2012 09:30:20 PM CDT Local ID db50d35a-1a8c-4e53-a4ae-98765dcb81db
Raw Audit Messages type=AVC msg=audit(1334889020.147:6): avc: denied { read } for pid=633 comm="dmesg" name="ld.so.cache" dev="dm-1" ino=54745 scontext=system_u:system_r:dmesg_t:s0 tcontext=unconfined_u:object_r:etc_t:s0 tclass=file
Hash: dmesg,dmesg_t,etc_t,file,read
audit2allowunable to open /sys/fs/selinux/policy: Permission denied
audit2allow -Runable to open /sys/fs/selinux/policy: Permission denied
What do I do, please advice. I am getting annoyed, frustrated and I would hate to kill off selinux, because I actually like it, but the NOT A BUG does bother me. I have had the past three or four days dealing with this, and now I am finally doing something about it :(
Thanks for listening.
Regards,
Antonio
selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
I have just reopened the bug.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Somehow /etc/ld.so.cache file got mislabeled? Was this an initial install? Install from livecd? Running restorecon on /etc/ld.so.cache will fix the label, as the setroubleshoot tells you. Does the file become mislabeled again?
If we could figure out how it got mislabeled we would gladly fixed it, if we get one bug from one person reporting a file is mislabeled, and do not hear about it from others, we assume it is a one off and tell the user to follow what setroubleshoot told them to do. If we see it repeatedly or from multiple users we will do our best to investigate what is going on.
We have a rule in policy now that says if any unconfined domain creates this file it will get labeled correctly, This include unconfined_t, initrc_t, rpm_t, rpm_script_t. So I do not know how it got mislabeled. Does the file first get created with a different name and then renamed to /etc/ld.so.cache_t?
--- On Fri, 4/20/12, Daniel J Walsh dwalsh@redhat.com wrote:
From: Daniel J Walsh dwalsh@redhat.com Subject: Re: https://bugzilla.redhat.com/show_bug.cgi?id=812100 To: "For testing and quality assurance of Fedora releases" test@lists.fedoraproject.org Cc: "Antonio Olivares" olivares14031@yahoo.com, "Selinux List at Fedora Project" selinux@lists.fedoraproject.org Date: Friday, April 20, 2012, 5:37 AM -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Somehow /etc/ld.so.cache file got mislabeled? Was this an initial install? Install from livecd?
Installed from nightly build before rc4 and/or beta was released.
Running restorecon on /etc/ld.so.cache will fix the label, as the setroubleshoot tells you. Does the file become mislabeled again?
Will try it later tonight and see what happens.
If we could figure out how it got mislabeled we would gladly fixed it, if we get one bug from one person reporting a file is mislabeled, and do not hear about it from others, we assume it is a one off and tell the user to follow what setroubleshoot told them to do. If we see it repeatedly or from multiple users we will do our best to investigate what is going on.
We have a rule in policy now that says if any unconfined domain creates this file it will get labeled correctly, This include unconfined_t, initrc_t, rpm_t, rpm_script_t. So I do not know how it got mislabeled. Does the file first get created with a different name and then renamed to /etc/ld.so.cache_t?
Regards,
Antonio
selinux@lists.fedoraproject.org
-
Antonio Olivares -
Daniel J Walsh -
Miroslav Grepl