Bug 818528
Summary: | SELinux is preventing /usr/bin/python2.7 from 'write' accesses on the file network.state. | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | nordaux |
Component: | blueman | Assignee: | Juan Manuel Rodriguez <nushio> |
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 17 | CC: | christoph.wickert, dominick.grift, dwalsh, mgrepl, misek, netwizurd, nordaux, nushio |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Unspecified | ||
Whiteboard: | abrt_hash:2c0e332e26ee419d19664a7958b24da6e991155ead89f8d61929f0a0392d61ef | ||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2013-08-01 18:47:00 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
nordaux
2012-05-03 09:23:47 UTC
Do you know what directory is blueman trying to write network.state in? Does blueman need to write content into the /var/lib directory? Hey Dan, I've been reading your Selinux blog... man I got things to learn ! I'm getting roughly the same thing as Nordaux. But it is not coming out in Abrt, I'm only getting Selinux Alerts. I could not automatically post this. So I did not know if I needed to open a new bug. Since it's on the same file and seams to be from "blueman_t" too... thought I would post it here. My install is Xfce and LXDE only... no Gnome3 "Crazies". http://digitizor.com/2011/08/04/linus-torvalds-ditches-gnome-for-xfce/ I do run GDM as LXDM was starting but not showing a login box. I have 4 the alerts : Read, Open, getattr and Write. Only the getattribute display full path, the 3 others only specify the file name. -rw-r--r--. 1 root root 136 May 3 15:44 /var/lib/blueman/network.state ******************************************************************************* SELinux is preventing blueman-mechani from getattr access on the file /var/lib/blueman/network.state. ***** Plugin catchall_labels (83.8 confidence) suggests ******************** If you want to allow blueman-mechani to have getattr access on the network.state file Then you need to change the label on /var/lib/blueman/network.state Do # semanage fcontext -a -t FILE_TYPE '/var/lib/blueman/network.state' where FILE_TYPE is one of the following: net_conf_t, userdomain, rpm_script_tmp_t, blueman_t, ld_so_cache_t, abrt_var_cache_t, sosreport_tmp_t, avahi_exec_t, rpm_tmp_t, abrt_var_run_t, cert_t, blueman_exec_t, etc_t, sysctl_crypto_t, system_dbusd_var_lib_t, sssd_public_t, locale_t, bin_t, etc_t, proc_t, passwd_file_t, krb5_conf_t, usr_t, abrt_t, lib_t, ld_so_t, cpu_online_t, abrt_helper_exec_t, passwd_file_t, samba_var_t, textrel_shlib_t, dbusd_etc_t, krb5_host_rcache_t. Then execute: restorecon -v '/var/lib/blueman/network.state' ***** Plugin catchall (17.1 confidence) suggests *************************** If you believe that blueman-mechani should be allowed getattr access on the network.state 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 blueman-mechani /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:blueman_t:s0-s0:c0.c1023 Target Context system_u:object_r:var_lib_t:s0 Target Objects /var/lib/blueman/network.state [ file ] Source blueman-mechani Source Path blueman-mechani Port <Unknown> Host Think.Dawg Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.10.0-118.fc17.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name Think.Dawg Platform Linux Think.Dawg 3.3.4-1.fc17.i686 #1 SMP Fri Apr 27 19:40:35 UTC 2012 i686 i686 Alert Count 1 First Seen Thu 03 May 2012 03:44:23 PM EDT Last Seen Thu 03 May 2012 03:44:23 PM EDT Local ID c0409e0f-99cb-4051-a515-8cb6d15bf5ad Raw Audit Messages type=AVC msg=audit(1336074263.451:235): avc: denied { getattr } for pid=1334 comm="blueman-mechani" path="/var/lib/blueman/network.state" dev="dm-1" ino=394995 scontext=system_u:system_r:blueman_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_lib_t:s0 tclass=file Hash: blueman-mechani,blueman_t,var_lib_t,file,getattr audit2allowunable to open /sys/fs/selinux/policy: Permission denied audit2allow -Runable to open /sys/fs/selinux/policy: Permission denied ******************************************************************************* I hope this pertains to the same issue... if not... wath to do ? /var/lib/blueman is not owned by blueman package. Is this directory created by the blueman-mechanism? Also could you add this directory to the spec file, then we can add a label for it and this directory get the right labeling on the install. (In reply to comment #2) > Does blueman need to write content into the /var/lib directory? Yes, it keeps a file called /var/lib/blueman/network.state (In reply to comment #4) > /var/lib/blueman is not owned by blueman package. My bad. > Is this directory created by the blueman-mechanism? Yes. > Also could you add this directory to the spec file, then we can add a label for > it and this directory get the right labeling on the install. Sure, I will push an update. Note: I am not the owner of the package, I just jumped in because this package has so many bugs. blueman-1.23-2.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/blueman-1.23-2.fc17 blueman-1.23-2.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/blueman-1.23-2.fc16 Sweeeeeeeeeeeeeeeeeeeeet ! blueman-1.23-2.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report. Much obliged. blueman-1.23-2.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report. 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. |