Bug 653108
Summary: | SELinux is preventing /sbin/killall5 from getattr access on the file /usr/sbin/hald. | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Tom <thomasbelvin> |
Component: | selinux-policy | Assignee: | Miroslav Grepl <mgrepl> |
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | rawhide | CC: | dwalsh, jreznik, kevin, ltinkl, mgrepl, olivares14031, oliver.henshaw, rdieter, rh-bugzilla, rnovacek, ry, smparrish, than, thomasj |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | setroubleshoot_trace_hash:10f160aa3f2935ca23fcd238f0c877454d4acb377146ff168d2ae8932dbbfcab | ||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2011-02-02 19:18:19 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: | |||
Attachments: |
Description
Tom
2010-11-14 15:40:17 UTC
*** Bug 653111 has been marked as a duplicate of this bug. *** *** Bug 653112 has been marked as a duplicate of this bug. *** *** Bug 653113 has been marked as a duplicate of this bug. *** *** Bug 653114 has been marked as a duplicate of this bug. *** *** Bug 653115 has been marked as a duplicate of this bug. *** *** Bug 653116 has been marked as a duplicate of this bug. *** *** Bug 653117 has been marked as a duplicate of this bug. *** *** Bug 653118 has been marked as a duplicate of this bug. *** *** Bug 653119 has been marked as a duplicate of this bug. *** *** Bug 653120 has been marked as a duplicate of this bug. *** *** Bug 653121 has been marked as a duplicate of this bug. *** *** Bug 653122 has been marked as a duplicate of this bug. *** *** Bug 653123 has been marked as a duplicate of this bug. *** *** Bug 653124 has been marked as a duplicate of this bug. *** *** Bug 653126 has been marked as a duplicate of this bug. *** *** Bug 653127 has been marked as a duplicate of this bug. *** *** Bug 653128 has been marked as a duplicate of this bug. *** *** Bug 653129 has been marked as a duplicate of this bug. *** Were you suspending the machine from the login screen? Also if you get a ton of avc's that look the same, please do not report them all, report one and then comment on having multiple that look the same. Otherwise we have to go through and close them as duplicates. Locking screen after logging in. Sorry about all the multiple reports. I get the /sbin/killall5 warnings just after logging in, without suspending. Hi, I see these messages only when I directly log in into kde (graphical login). When I first start in text mode (3) then start kdm these messages don't appear...huh? To see when the messages happen I'll attach my /var/log/message file. Martin Kho Created attachment 460676 [details]
/var/log/message
Hi, Sorry, forgot to tell which version of selinux-policy I'm running: selinux-policy-3.9.8-6.fc15.noarch Martin Kho kde maintainers, is kde executing hal now? I just booted kde-x86_64-20101214.16.iso which still has this problem. hal is still on the image, pulled in by smolt and blueman. To answer comment #26 , kde in rawhide currently no longer uses hal at all. I booted the nightly iso to runlevel 3 and removed hal and its dependants. Then when I 'init 5' I still see similar messages mentioning killall5 and getattr access for a range of binaries (as in the duplicated bugs). Please attach the output of ausearch -m avc Created attachment 468973 [details]
'ausearch -m avc' for kde-x86_64-20101214.iso
Does anyone know if pidof change its behavior to stat all executable files that are currently running? Hi, I've tried a recent desktop live build [1] and I don't get these messages. So this issue seems to be specific for kde? Martin Kho [1] http://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/desktop-x86_64-20110124.16.iso The GNOME spin no longer includes HAL. The KDE spin still does. So that's why you're only seeing this on the KDE spin. But there shouldn't be any HAL on the KDE spin in the first place. It's being dragged in by blueman, a non-KDE app. Why is this even on our spin? We have bluedevil already. I'm removing blueman from the KDE spin kickstart. Actually this is a packaging issue, bluedevil doesn't Provides: dbus-bluez-pin-helper, so blueman gets dragged in. Provides added in bluedevil-1.0.1-2.fc15, we shouldn't have HAL on the KDE spin once the build makes it through. But the underlying issue here still needs fixing, as long as HAL is still in the distro. Hi Kevin, I'm not sure if hal and or bluedevil/man is the cause of the issue. I had bluedevil nor blueman installed - kbluetooth was still installed. Installing bluedevil-1.0.1-2 didn't made the situation any better ;-(. Sorry Martin Kho Btw when I run yum remove hal it seems no other package than "hal-storage-addon" and "hal-info" will be removed. Are there dependencies missing? Hi again, .. and trying kde nightly build [1] - with bluedevil/-man - also gives my the killall messages when I log in. Martin Kho [1] kde-i386-20110126.16.iso HAL is the cause of the issue. The blue* issue is only what's dragging HAL onto the nightly live images (bluedevil → bluez → blueman → hal dependency chain, the bluez → blueman item is the issue, blueman got selected as the provider for dbus-bluez-pin-helper because bluedevil was missing the Provides). On your system, HAL is present for another reason; I suppose you installed when HAL was still a dependency of many things, it should be safe to remove now. Hi Kevin, Okay, I did remove HAL and everything seems fine. Besides, I did a little test: 1. Boot into runlevel 3 -> log in as root -> issue /usr/bin/kdm -nodaemon -> Switched to the command prompt (ctrl_alt-F2, not logging in into kde) -> the killall5 messages didn't appear in var/log/messages, huh? Attached in comment #41 you'll find the output from ps axf (boot_rnlvl3) 2. Boot into runlevel 5 -> Switched to the command prompt (ctrl-alt-F2, not logging in into kde) -> in /var/log/messages the killall5 messages appear. Attached in comment #42 you'll find again the output from ps axf (boot_rnlvl5) The big difference between the two outputs, for so far I can see, is "/usr/bin/system-setup-keyboard". It's started in runlevel 5 and not when I first boot into runlevel 3. May be this can give some clue? Martin Kho Created attachment 475955 [details]
ps axf output runlevel 3
Created attachment 475956 [details]
ps axf output runlevel 5
Hi Kevin, I think there is a misunderstanding about what what you and me mean by 'issue'. Your usage of the term has to do with the dependency of blue* on HAL. Mine has to do with the killall5 selinux messages that appear in /var/log/messages and the pop up appearing after I log in into kde. Right? Martin Kho Re: comment #40, test 1: In comment #29 I booted into runlevel 3 -> login as root -> init 5 and still saw the killall5 messages. So perhaps it is something started in runlevel 5, or perhaps kdm is started differently? I've noticed that I see more killall5 avc's after logging off and logging back on through kdm (on the livecd). So I used 'ausearch -m avc ~ wc -l' in vt2 as a crude way of testing whether the number of avc's had grown - I found that avc's are triggered when logging out of kde, or just when restarting X from kdm, but not when logging in from kdm. I don't think that hald is the cause of the problem either. Though note that hal-libs (but not hal) is still pulled in by gnome-vfs2, iirc. This seems to be thanks to abrt-gui, system-config-* and some other system gui's, last time I checked. I think that some of the system-config-* packages are only brought in by the kde spin kickstart and aren't gnome desktop spin, but the others should be gnome's problem too. Can you attach the AVC messages you are seeing then? Created attachment 476626 [details]
'ausearch -m avc' after bootup and autologin for kde-x86_64-20110131.14.iso
Created attachment 476627 [details]
'ausearch -m avc -ts recent' after logout for kde-x86_64-20110131.14.iso
Created attachment 476629 [details]
'ausearch -m avc -ts recent' after restart x from kdm for kde-x86_64-20110131.14.iso
Fixed in the next version of policy, added dontaudit. Probably a dumb question, but could this have had as similar cause to bug #669672? Not sure how? ioctl's with unexpected permissions? Like I said, probably a dumb question. |