Description of problem: Version-Release number of selected component (if applicable): SELinux prevents that the scanner of our HP all in one device. Disabling SELinux "solves" this. From the logs: Sep 29 12:44:57 hibbert hpiod: unable to bind socket 2208: Permission denied Sep 29 12:44:58 hibbert kernel: audit(1159526697.637:10): avc: denied { name_b ind } for pid=3521 comm="hpiod" src=2208 scontext=user_u:system_r:hplip_t:s0 tc ontext=system_u:object_r:port_t:s0 tclass=tcp_socket Sep 29 12:45:08 hibbert xsane: unable to open /var/run/hpiod.port: Onbekend best and of map: prnt/hpijs/hplip_api.c 84 Sep 29 12:45:08 hibbert xsane: unable to connect hpiod socket 50000: Verbinding geweigerd: prnt/hpijs/hplip_api.c 702 Sep 29 12:45:08 hibbert xsane: ProbeDevices(): unable to send message: Slechte b estandsbeschrijver How reproducible: Always Steps to Reproduce: 1. Set SELinux to enforcing 2. launch GIMP + XSane 3. Try to scan Actual results: "No devices found" Expected results: Be able to scan. Additional info:
What version of policy are you seeing this with. Looks like this should work with the current rawhide policy?
I just did a yum update which broke pretty much everything. I won't be able to do a full reinstall before Monday.
Ok I am marking this fixed in rawhide. Reopen if you find it to still be a problem,
# rpm -q selinux-policy selinux-policy-2.3.17-1 Still I get: Oct 3 09:40:01 hibbert hpiod: unable to bind socket 2208: Permission denied Oct 3 09:40:03 hibbert kernel: audit(1159861201.610:11): avc: denied { name_bind } for pid=3465 comm="hpiod" src=2208 scontext=user_u:system_r:hplip_t:s0 tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket
Please execute the following # semanage port -l | grep 2208 hplip_port_t tcp 9290, 1782, 2207, 2208, 50000, 50002, 8292, 9100, 9101, 9102, 9220, 9221, 9222, 9280, 9281, 9282, 9290, 9291, 9292 This should work.
[root@hibbert ~]# semanage port -l | grep 2208 [root@hibbert ~]# This is a really default install of fc6t3.
Ehr, really default install, with all updates up until now of course :P
Seems like something is wrong with your install Could you try semodule -b /usr/share/selinux/targeted/base.pp semanage port -l | grep 2208
That's weird. I did a complete fresh install yesterday morning, then yum update for the rest of the day. # semodule -b /usr/share/selinux/targeted/base.pp libsemanage.semanage_commit_sandbox: Could not remove previous backup /etc/selinux/targeted/modules/previous. From /var/log/messages: Oct 3 17:30:20 hibbert kernel: audit(1159889419.269:23): avc: denied { rmdir } for pid=5159 comm="semodule" name="modules" dev=dm-0 ino=10301441 scontext=user_u:system_r:semanage_t:s0 tcontext=system_u:object_r:selinux_config_t:s0 tclass=dir
Try restorecon -R -v /etc/selinux/targeted semodule -b /usr/share/selinux/targeted/base.pp
# semodule -b /usr/share/selinux/targeted/base.pp libsemanage.semanage_install_active: Could not copy /etc/selinux/targeted/modules/active/netfilter_contexts to /etc/selinux/targeted/contexts/netfilter_contexts. semodule: Failed! Oct 3 17:38:03 hibbert dbus: Can't send to audit system: USER_AVC avc: received policyload notice (seqno=4) : exe="/bin/dbus-daemon" (sauid=501, hostname=?, addr=?, terminal=?) Oct 3 17:38:03 hibbert kernel: audit(1159889883.098:28): avc: denied { write } for pid=5190 comm="semodule" name="contexts" dev=dm-0 ino=10268807 scontext=user_u:system_r:semanage_t:s0 tcontext=system_u:object_r:default_context_t:s0 tclass=dir Oct 3 17:38:03 hibbert kernel: security: 3 users, 6 roles, 1479 types, 154 bools, 1 sens, 256 cats Oct 3 17:38:03 hibbert kernel: security: 58 classes, 43992 rules Oct 3 17:38:03 hibbert dbus: Can't send to audit system: USER_AVC avc: received policyload notice (seqno=4) : exe="?" (sauid=81, hostname=?, addr=?, terminal=?) Oct 3 17:38:05 hibbert kernel: audit(1159889883.410:29): policy loaded auid=4294967295 If it is screwed up (it seems like something is), then I don't know why it is screwed up. OTOH, a friend just reported that he could start all the daemons, with SELinux running. My best guess is that somehow during upgrading with yum (did a vanilla install twice on this machine, then yum update, both times it failed) things went wrong. Hm. Hm. Hm. Very strange. I will install it tonight on another machine and retest everything tomorrow. If it then works, then this one can be closed.
Fixed in selinux-policy-2.3.18-2
Hm, still doesn't work. As I'm only seeing it on my machine (x86_64) and not on a normal i386 machine I'm changing the hardware type. Maybe it would be best to try and hunt down this bug until after FC6 has been released? I will do a complete reinstall then anwyay. Maybe it is is just some cruft that was a left over from an old test install...
Is semodule still failing to load the policy?
Yes, I still get the same errors as before.
Can you just try load_policy Then try the semodulecommand?
Same errors. Is there any way I can easily reset the policy, then load a new one (disabling SELinux, then enabling it again)? What is the proper way to do this and would it make sense?
setenforce 0 load_policy setenforce 1
setenforce 0 load_policy semodule <blah> setenforce 1 reboot that fixed my problems. Now my only question is why this is going wrong in the first place. Probably it's still old cruft. I will retest once FC6 is released. Thanks!
I don't have access to this device anymore, so I can't retest :(