Description of problem: When inserting ipod the following is in dmesg: usb 1-5: new high speed USB device using ehci_hcd and address 5 usb 1-5: configuration #1 chosen from 2 choices scsi6 : SCSI emulation for USB Mass Storage devices usb 1-5: New USB device found, idVendor=05ac, idProduct=1209 usb 1-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-5: Product: iPod usb 1-5: Manufacturer: Apple usb 1-5: SerialNumber: 000A27001615FDB7 usb-storage: device found at 5 usb-storage: waiting for device to settle before scanning usb-storage: device scan complete scsi 6:0:0:0: Direct-Access Apple iPod 1.62 PQ: 0 ANSI: 0 sd 6:0:0:0: [sdc] 39075372 2048-byte hardware sectors (80026 MB) sd 6:0:0:0: [sdc] Write Protect is off sd 6:0:0:0: [sdc] Mode Sense: 68 00 00 08 sd 6:0:0:0: [sdc] Assuming drive cache: write through sd 6:0:0:0: [sdc] 39075372 2048-byte hardware sectors (80026 MB) sd 6:0:0:0: [sdc] Write Protect is off sd 6:0:0:0: [sdc] Mode Sense: 68 00 00 08 sd 6:0:0:0: [sdc] Assuming drive cache: write through sdc: sdc1 sdc2 sd 6:0:0:0: [sdc] Attached SCSI removable disk sd 6:0:0:0: Attached scsi generic sg3 type 0 SELinux: initialized (dev sdc2, type vfat), uses genfs_contexts Clearly the ipod is detected, but podsleuth outputs: david@localhost:~$ podsleuth --rescan No iPods were found in the HAL device tree Version-Release number of selected component (if applicable): ipod-sharp-0.8.0-4.fc9.x86_64 libipoddevice-0.5.3-4.fc9.x86_64 libipoddevice-0.5.3-4.fc9.i386 podsleuth-0.6.0-5.fc8.x86_64 How reproducible: 100% Steps to Reproduce: 1. install podsleuth 2. reboot (or restart hal) 3. insert ipod 4. run podsleuth command Actual results: No ipod, denied! Expected results: iPod joy Additional info:
Can you grab the output of lshal?
I have been able to reproduce this I've actually been meaning to get some more info on this. Out of interest, does your iPod appear on: http://banshee-project.org/files/podsleuth/ipod-model-table ?
Created attachment 304202 [details] lshal output The requested lshal output. My iPod does appear on that list and strangely this used to work earlier in the F9 cycle.
(In reply to comment #3) > Created an attachment (id=304202) [edit] > lshal output > > The requested lshal output. Very helpful > > My iPod does appear on that list and strangely this used to work earlier in the > F9 cycle. Compared to my F8 machine, this output is very bland! There *should* be a good 15 odd entries starting with org.podsleuth.ipod with the serial number, colour, model name, capabilities etc. I'm going to test on rawhide in a few minutes.
I am tempted to think this is a dbus/ndesk-dbus issue. Now I don't even get the report back that there are no ipods in the hal tree. I did manage to trick it into telling me that Unhandled Exception: System.Exception: org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus) at IManagerProxy.FindDeviceStringMatch (System.String value, System.String ) [0x00000] at Hal.Manager.FindDeviceByStringMatch (System.String key, System.String value) [0x00000] at Hal.Manager.FindDeviceByStringMatchAsDevice (System.String key, System.String value) [0x00000] at PodSleuth.HalFrontend.HalClient.Run (System.String[] args) [0x00000] at PodSleuth.HalFrontend.HalEntry.Main (System.String[] args) [0x00000] I tried backing ndesk-dbus down to 0.6.0 using epoch and explicitly telling podsleuth at compile time to expect the updates in /usr/lib64/podsleuth but had no luck. It does not appear that ndesk-dbus is interfacing with dbus at all.
And we have the following AVC from SELinux when invoking podsleuth: host=localhost.localdomain type=AVC msg=audit(1210070168.524:19): avc: denied { getsched } for pid=2998 comm="mono" scontext=system_u:system_r:hald_t:s0 tcontext=system_u:system_r:hald_t:s0 tclass=process host=localhost.localdomain type=SYSCALL msg=audit(1210070168.524:19): arch=c000003e syscall=145 success=no exit=-13 a0=bb6 a1=7fc42cfd0ba8 a2=d a3=367e966fac items=0 ppid=2994 pid=2998 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mono" exe="/usr/bin/mono" subj=system_u:system_r:hald_t:s0 key=(null) Adding Dan Walsh to CC for input. Using selinux-policy-3.3.1-44.fc9
(In reply to comment #6) > And we have the following AVC from SELinux when invoking podsleuth: > > host=localhost.localdomain type=AVC msg=audit(1210070168.524:19): avc: denied { > getsched } for pid=2998 comm="mono" scontext=system_u:system_r:hald_t:s0 > tcontext=system_u:system_r:hald_t:s0 tclass=process > > host=localhost.localdomain type=SYSCALL msg=audit(1210070168.524:19): > arch=c000003e syscall=145 success=no exit=-13 a0=bb6 a1=7fc42cfd0ba8 a2=d > a3=367e966fac items=0 ppid=2994 pid=2998 auid=4294967295 uid=0 gid=0 euid=0 > suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mono" > exe="/usr/bin/mono" subj=system_u:system_r:hald_t:s0 key=(null) > > Adding Dan Walsh to CC for input. > > Using selinux-policy-3.3.1-44.fc9 Thanks for that I was able to reproduce but I've been so busy that I was unable to get through all the debugging stages yet.
I've got some more juicy SELinux goodness, I'll attach it soon when I've got all the sealert stuff.
Created attachment 304627 [details] SELinux AVCs - Enforcing Mode
Created attachment 304628 [details] SELinux AVCs - Permissive Mode
(In reply to comment #9) > Created an attachment (id=304627) [edit] > SELinux AVCs - Enforcing Mode (In reply to comment #10) > Created an attachment (id=304628) [edit] > SELinux AVCs - Permissive Mode In both instances I have reattached the iPod (unplug, plugin) and issued 'mount /dev/sdx2 /mnt'. The reported problem still seems to occur, but I'm wondering if thats a smoke screen, I don't really feel like turning SELinux off on that install, I might clone the machine and try again though. Would really appreciate the assistance of our SELinux gurus though
I turned SELinux off completely for testing purposes, and Banshee from SVN shows the iPod correctly but podsleuth still reports no ipod in the device tree. So we have two bugs, the SELinux one and then once that is resolved figuring out why podsleuth hates us. Want to file a bug against the selinux-policy package?
Created attachment 304639 [details] I just hacked together some podsleuth policy. If you untar this tar ball and run the .sh script it will compile and install the selinux policy module then run attempt to use podsleuth, Send me any additional avc messages.
With a newly relabelled system and this module installed I get this when inserting the iPod (thus making the default action dialog pop up). host=localhost.localdomain type=AVC msg=audit(1210151433.916:20): avc: denied { getsched } for pid=2931 comm="mono" scontext=system_u:system_r:hald_t:s0 tcontext=system_u:system_r:hald_t:s0 tclass=process host=localhost.localdomain type=SYSCALL msg=audit(1210151433.916:20): arch=c000003e syscall=145 success=no exit=-13 a0=b73 a1=7fc0335a2ba8 a2=d a3=3b9bd66fac items=0 ppid=2929 pid=2931 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mono" exe="/usr/bin/mono" subj=system_u:system_r:hald_t:s0 key=(null)
Created attachment 304759 [details] audit log An audit log for Dan to play with
Well I don't know how you did it but /dev/null is labeled incorrectly # restorecon /dev/null Also you need to relabel your homedir for nsplugin to work better. restorecon -R -v ~ I got a couple of avc's for nsplugin that I will fix in the next Fedora 9 selinux-policy package # restorecon -R -v /var/log Could you attach the corrected podsleuth.te, fc files
Created attachment 304774 [details] podsleuth.fc
Created attachment 304776 [details] podsleuth.te I've performed the requested tasks and attached the files you requested.
I've cloned the original problem as bug #445611 I'll post the updated selinux policy that I have shortly.
Created attachment 304847 [details] Updated SELinux Policy After discussions online with the SELinux crew, this policy gets rid of most of the AVCs, not all, I'll provide an updated RPM when I've managed to get them all. You'll want to add: /usr/libexec/hal-podsleuth -- gen_context(system_u:object_r:podsleuth_exec_t,s0) To podsleuth.fc too, and run /sbin/restorecon -F -R -v /usr/libexec/hal-podsleuth Also the var_run_podsleuth stuff is WIP which I'll be able to concentrate on later this week
Fixed in selinux-policy-3.3.1-49.fc9.noarch
selinux-policy-3.3.1-49.fc9.noarch not found in koji and so far as I can tell from CVS no such change has been checked in. Reopening till the bug can be comfirmed fixed or at least an rpm is available for testing.
Created attachment 305021 [details] Updated SELinux Policy Okay, new version with more fixes etc. Note, testers will need to change the last few lines in /usr/libexec/hal-podsleuth to: rm -f $DEBUG_PATH mkdir /tmp/podsleuth.wapi MONO_SHARED_DIR=/tmp/podsleuth.wapi $MONO $MONO_ARGS $MONO_EXEC $MONO_EXEC_ARGS &> $DEBUG_PATH && { rm -f $DEBUG_PATH rm -rdf /tmp/podsleuth.wapi } I'll sort this out later today, but this has 0 AVCs in Enforcing mode.
I am still experiencing problems that relates to this, connecting to the messagebus times out when SELinux is enforcing. This makes podsleuth not work and it causes the startup time for banshee to be counted in double digit minutes. type=USER_AVC msg=audit(1210553612.168:104): user pid=1942 uid=81 auid=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg } for msgtype=method_return dest=:1.77 spid=2008 tpid=3440 scontext=system_u:system_r:hald_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_mono_t:s0-s0:c0.c1023 tclass=dbus : exe="/bin/dbus-daemon" (sauid=81, hostname=?, addr=?, terminal=?)' This is with selinux-policy-3.3.1-49
(In reply to comment #24) > I am still experiencing problems that relates to this, connecting to the > messagebus times out when SELinux is enforcing. This makes podsleuth not work > and it causes the startup time for banshee to be counted in double digit minutes. > > type=USER_AVC msg=audit(1210553612.168:104): user pid=1942 uid=81 > auid=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: > denied { send_msg } for msgtype=method_return dest=:1.77 spid=2008 tpid=3440 > scontext=system_u:system_r:hald_t:s0 > tcontext=unconfined_u:unconfined_r:unconfined_mono_t:s0-s0:c0.c1023 tclass=dbus > : exe="/bin/dbus-daemon" (sauid=81, hostname=?, addr=?, terminal=?)' > > This is with selinux-policy-3.3.1-49 The policy works with -42 (current rawhide version). I'd be prepared to bet that 3.3.1-44 broke the policy as the transition is no longer occurring. Any thoughts Dan?
Created attachment 305238 [details] New Podsleuth Policy Okay, here is the latest podsleuth policy that I have, seems to work great. If merged upstream, the hald_t line needs to be merged into the hald policy.
Fixed in selinux-policy-3.3.1-51.fc9.noarch
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I've got all the updated pieces including podsleuth-0.6.0-6.fc9.x86_64 and selinux-policy-targeted-3.3.1-51.fc9.noarch, rebooted and relabeled, but still get SELinux is preventing hal-podsleuth (podsleuth_t) "getattr" to /usr/bin/mono (mono_exec_t). when attaching my ipod shuffle. Going to permissive mode allows it to work.
That is strange. I am seeing that access. allow podsleuth_t mono_exec_t : file { ioctl read getattr lock execute execute_no_trans }; Could you attach the avc message?
Here you go: host=raptor.sr.unh.edu type=AVC msg=audit(1210969433.925:302): avc: denied { getattr } for pid=16961 comm="hal-podsleuth" path="/usr/bin/mono" dev=dm-0 ino=296345 scontext=system_u:system_r:podsleuth_t:s0 tcontext=system_u:object_r:mono_exec_t:s0 tclass=file host=raptor.sr.unh.edu type=SYSCALL msg=audit(1210969433.925:302): arch=c000003e syscall=4 success=no exit=-13 a0=1042a00 a1=7fff94b57880 a2=7fff94b57880 a3=0 items=0 ppid=2583 pid=16961 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="hal-podsleuth" exe="/bin/bash" subj=system_u:system_r:podsleuth_t:s0 key=(null)
Argh, this is (cuse the pun) really bugging me now. I get the same AVC with -51 on my desktop now (fresh reinstall with KDE): # audit2allow host=localhost.localdomain type=AVC msg=audit(1211276419.133:90): avc: denied {getattr } for pid=10534 comm="hal-podsleuth" path="/usr/bin/mono" dev=sdb2 ino=1319940 scontext=system_u:system_r:podsleuth_t:s0 tcontext=system_u:object_r:mono_exec_t:s0 tclass=file host=localhost.localdomain type=SYSCALL msg=audit(1211276419.133:90): arch=c000003e syscall=4 success=no exit=-13 a0=b42440 a1=7fff9514fce0 a2=7fff9514fce0 a3=0 items=0 ppid=1960 pid=10534 auid=4294967295 uid=0 gid=0euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="hal-podsleuth" exe="/bin/bash" subj=system_u:system_r:podsleuth_t:s0 key=(null) #============= podsleuth_t ============== allow podsleuth_t mono_exec_t:file getattr;
This package has now been orphaned, hopefully someone will be able to pick it up and resolve the reported bug soon.
This has been fixed for a while.