Description of problem: Just booting. Looks like user installed pacakages in ~/.local/lib/python3.11/ is the reason. SELinux is preventing blueman-mechani from 'read' accesses on the lnk_file lib. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that blueman-mechani should be allowed read access on the lib lnk_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: # ausearch -c 'blueman-mechani' --raw | audit2allow -M my-bluemanmechani # semodule -X 300 -i my-bluemanmechani.pp Additional Information: Source Context system_u:system_r:blueman_t:s0 Target Context unconfined_u:object_r:gconf_home_t:s0 Target Objects lib [ lnk_file ] Source blueman-mechani Source Path blueman-mechani Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-37.19-1.fc37.noarch Local Policy RPM selinux-policy-targeted-37.19-1.fc37.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name (removed) Platform Linux (removed) 6.1.18-200.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Mar 11 16:09:14 UTC 2023 x86_64 x86_64 Alert Count 8 First Seen 2023-03-14 12:04:11 EET Last Seen 2023-03-20 08:13:30 EET Local ID 418a759b-bf24-4e28-9165-f16296d1e9c0 Raw Audit Messages type=AVC msg=audit(1679292810.649:1288): avc: denied { read } for pid=7511 comm="blueman-mechani" name="lib" dev="dm-0" ino=24010461 scontext=system_u:system_r:blueman_t:s0 tcontext=unconfined_u:object_r:gconf_home_t:s0 tclass=lnk_file permissive=1 Hash: blueman-mechani,blueman_t,gconf_home_t,lnk_file,read Version-Release number of selected component: selinux-policy-targeted-37.19-1.fc37.noarch Additional info: component: selinux-policy reporter: libreport-2.17.4 hashmarkername: setroubleshoot kernel: 6.1.18-200.fc37.x86_64 type: libreport
Hello Doncho, Can you check if the following local module is sufficient? f38# cat local_blueman.cil (allow blueman_t gconf_home_t (lnk_file (read))) f38# semodule -i local_blueman.cil
Added the module: semodule -l | grep ^local_ SIGUSR1 to auditd (rotate logs) cat /var/log/audit/audit.log | grep blueman type=AVC msg=audit(1680183089.654:1217): avc: denied { read } for pid=52308 comm="blueman-mechani" name="easy-install.pth" dev="dm-0" ino=20487705 scontext=system_u:system_r:blueman_t:s0 tcontext=unconfined_u:object_r:gconf_home_t:s0 tclass=file permissive=1 type=AVC msg=audit(1680183089.654:1218): avc: denied { open } for pid=52308 comm="blueman-mechani" path="/home/dgunchev/.local/lib/python3.11/site-packages/easy-install.pth" dev="dm-0" ino=20487705 scontext=system_u:system_r:blueman_t:s0 tcontext=unconfined_u:object_r:gconf_home_t:s0 tclass=file permissive=1 type=AVC msg=audit(1680183089.654:1219): avc: denied { getattr } for pid=52308 comm="blueman-mechani" path="/home/dgunchev/.local/lib/python3.11/site-packages/easy-install.pth" dev="dm-0" ino=20487705 scontext=system_u:system_r:blueman_t:s0 tcontext=unconfined_u:object_r:gconf_home_t:s0 tclass=file permissive=1 type=AVC msg=audit(1680183089.654:1220): avc: denied { ioctl } for pid=52308 comm="blueman-mechani" path="/home/dgunchev/.local/lib/python3.11/site-packages/easy-install.pth" dev="dm-0" ino=20487705 ioctlcmd=0x5401 scontext=system_u:system_r:blueman_t:s0 tcontext=unconfined_u:object_r:gconf_home_t:s0 tclass=file permissive=1 type=AVC msg=audit(1680183089.658:1221): avc: denied { read } for pid=52308 comm="blueman-mechani" name="src" dev="dm-0" ino=693440 scontext=system_u:system_r:blueman_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir permissive=1 type=SERVICE_START msg=audit(1680183089.740:1222): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=blueman-mechanism comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'UID="root" AUID="unset" type=SERVICE_STOP msg=audit(1680183120.782:1243): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=blueman-mechanism comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'UID="root" AUID="unset" audit2allow < /var/log/audit/audit.log #============= blueman_t ============== allow blueman_t gconf_home_t:file { getattr ioctl open read }; allow blueman_t user_home_t:dir read; The following "fixes" things: cat local_blueman2.te module local_blueman2 1.0; require { type blueman_t; type user_home_t; type gconf_home_t; class lnk_file read; class file { getattr ioctl open read }; class dir read; } #============= blueman_t ============== allow blueman_t gconf_home_t:file { getattr ioctl open read }; allow blueman_t gconf_home_t:lnk_file read; allow blueman_t user_home_t:dir read;
Thank you. This line though seems to be unclear: what is location of the src directory and what is its label? type=AVC msg=audit(1680183089.658:1221): avc: denied { read } for pid=52308 comm="blueman-mechani" name="src" dev="dm-0" ino=693440 scontext=system_u:system_r:blueman_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir permissive=1 ls -lZd `find /home -inum 693440` Anyway, after rereading the bz it seems like a result of custom software installation which also needs to be taken care by the system administrator.
Interesting, this is drwxrwxr-x. 1 dgunchev dgunchev unconfined_u:object_r:user_home_t:s0 126 2022-11-28 12:20 /home/dgunchev/git/conductor/schedule/src I can see how it got there: cat /home/dgunchev/.local/lib/python3.11/site-packages/easy-install.pth /home/dgunchev/git/conductor/schedule/src /home/dgunchev/git/conductor/common/src and here is how it got there: pip3 install --upgrade-strategy=only-if-needed --user -e . This is actually an attempt for faster python development :-) Blueman definitely needs no access there, I tried /usr/bin/python3 -I /usr/bin/blueman-applet but that does not remove ~/.local/lib/python* form sys.path, and the only solution I can think of is to modify blueman to filter sys.path :-( even ChatGPT agrees.
I know why '-I' did not work, I had to add it to all files including libexec: $ rpm -ql blueman | grep '/usr/\(bin\|libexec\)/' /usr/bin/blueman-adapters /usr/bin/blueman-applet /usr/bin/blueman-manager /usr/bin/blueman-sendto /usr/bin/blueman-services /usr/bin/blueman-tray /usr/libexec/blueman-mechanism /usr/libexec/blueman-rfcomm-watcher Adding -I to the shebang fixes the issue. So this is not SELinux but rather python packaging problem? Maybe a guideline on all python packages to add '-I' or at least '-s'?
(In reply to Doncho Gunchev from comment #5) > Adding -I to the shebang fixes the issue. So this is not SELinux but rather > python packaging problem? Maybe a guideline on all python packages to add > '-I' or at least '-s'? Frankly I don't know. You may try to report it in the appropriate place. If no new information appears, I'll close this bz.
Thank you, this bug should be closed - not SELinux issue for sure. What would be the appropriate place to report? I can update the blueman spec file to incorporate that change but this should affect any python script ... start with blueman and see ask there?
I think I found my answer. $ head /usr/sbin/tuned #!/usr/libexec/platform-python -Es So in short this is Blueman packaging bug. Please close.
Closing per the last comment, thanks Doncho for digging deep.