Bug 411321 - sound drivers created with different ownership/permission
sound drivers created with different ownership/permission
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: pilot-link (Show other bugs)
8
All Linux
low Severity low
: ---
: ---
Assigned To: Ivana Varekova
Fedora Extras Quality Assurance
:
: 412581 (view as bug list)
Depends On:
Blocks: 158809 280251
  Show dependency treegraph
 
Reported: 2007-12-04 19:50 EST by Sammy
Modified: 2008-02-24 13:30 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-12-10 05:06:04 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Sammy 2007-12-04 19:50:38 EST
After the most recent updates all the sound devices are created with
root ownership and 0660 permission. As a condequence sound with KDE
pulseaudio, arts etc. fail. Normally, these files were owned by the
user e.g. user:root and ownership 0600.

I am reporting this to kernel since I do not see any other recent
updates that would cause this. If I am wrong please transfer.
Thanks
Comment 1 Leszek Matok 2007-12-05 11:50:11 EST
This happened to me yesterday, after upgrading my F8 with updates-testing enabled.

You're wrong though about the normal permissions - on my other two machines (one
is F8, upgraded with updates-testing disabled, second is rawhide), all files
under /dev/snd are root.root and 660 (and opening them as normal user works
miraculously).

Looking through rpm -qa --last, I see no package that I can suspect of causing
that, apart for the kernel (upgraded from 2.6.23.8-62.fc8 to 2.6.23.8-63.fc8),
but the kernel isn't the (only?) cause - downgrading to 2.6.23.8-62.fc8 or
2.6.23.1-49.fc8 doesn't help. That's why I think "kernel" is not the proper
component for this bug.

chmod o+rw /dev/snd/* is a short-term work-around for single-user systems, but
I'm wondering, what happened and how to fix it for good.
Comment 2 Leszek Matok 2007-12-05 12:21:55 EST
I just noticed a suspected program looking in dmesg (on two different kernels):
hal-acl-tool[3111]: segfault at 0ab66914 eip 00b80c4c esp bf8154f4 error 4
lines like this pop up whenever I log in (be it the GNOME session or plain VT)
with different "at" and "esp" addresses, but eip and error are the same. I've
never seen hal-acl-tool segfaulting before (confirmed by grep on /var/log).

The only hal-acl-tool I know about is /usr/libexec/hal-acl-tool from
hal-0.5.10-1.fc8. But there was no upgrade for hal in F8.

I also checked if any of the libs in `ldd /usr/libexec/hal-acl-tool` come from
an upgraded packages, with no success.

So I have a suspect, but I still don't know what caused it to break.
Comment 3 Espen Stefansen 2007-12-05 12:38:13 EST
I booted into kernel -77 and everything worked fine. I updated from updates-
testing and on the next reboot the sound didn't work. If it helps, here's the 
packages that got updated:
Dec 04 10:54:06 Updated: compiz-fusion - 0.6.0-7.fc8.i386
Dec 04 10:54:07 Updated: flash-plugin - 9.0.115.0-release.i386
Dec 04 10:54:14 Updated: firefox - 2.0.0.10-2.fc8.i386
Dec 04 10:56:04 Updated: compiz-fusion-gnome - 0.6.0-7.fc8.i386
Dec 04 11:04:14 Updated: createrepo - 0.4.11-1.fc8.noarch
Dec 04 11:04:15 Updated: python-telepathy - 0.14.0-4.fc8.noarch
Dec 04 11:04:18 Updated: shadow-utils - 2:4.0.18.1-20.fc8.i386
Dec 04 11:04:20 Updated: pilot-link - 2:0.12.2-9.fc8.i386
Dec 04 11:04:22 Updated: xorg-x11-server-Xorg - 1.3.0.0-36.fc8.i386
Dec 04 11:04:23 Updated: xorg-x11-server-utils - 7.3-2.fc8.i386
Dec 04 11:04:29 Updated: gdm - 1:2.20.2-2.fc8.i386
Dec 04 11:05:09 Updated: evolution - 2.12.2-2.fc8.i386
Dec 04 11:05:11 Updated: gnokii - 0.6.22-1.fc8.i386
Dec 04 11:05:12 Updated: libtheora - 1.0beta2-3.fc8.i386
Dec 04 11:05:15 Updated: ghostscript - 8.61-4.fc8.i386
Dec 04 11:05:17 Updated: poppler - 0.6.2-1.fc8.i386
Dec 04 11:05:21 Updated: rhythmbox - 0.11.3-5.fc8.i386
Dec 04 11:05:21 Updated: xen-libs - 3.1.2-1.fc8.i386
Dec 04 11:05:22 Updated: xorg-x11-drv-ati - 6.7.196-2.fc8.i386
Dec 04 11:05:26 Updated: freeciv - 2.1.1-1.fc8.i386
Dec 04 11:05:27 Updated: dcraw - 8.80-1.fc8.i386
Dec 04 11:05:47 Updated: BackupPC - 3.1.0-1.fc8.noarch
Dec 04 11:05:48 Updated: gdm-extra-faces - 1:2.20.2-2.fc8.i386
Comment 4 Leszek Matok 2007-12-05 13:32:40 EST
This was caused by pilot-link upgrade (can be because of a try to fix bug
158809). Downgrading pilot-link fixes the issue. Just don't ask me how many
reboots it required to make sure :)

I'm asking you to switch the component to hal. No matter, which package causes
HAL to break (pilot-link can blame udev, udev can blame kernel or something
else), a system as important as HAL to todays Fedora can't never, ever, segfault.

I'd change the component, but only the submitter can do that.

Meanwhile, I'm commenting in
https://admin.fedoraproject.org/updates/F8/FEDORA-2007-4050 to stop pilot-link
from being pushed to updates.
Comment 5 Pavol Šimo 2007-12-05 14:10:34 EST
(In reply to comment #1)
> You're wrong though about the normal permissions - on my other two machines (one
> is F8, upgraded with updates-testing disabled, second is rawhide), all files
> under /dev/snd are root.root and 660 (and opening them as normal user works
> miraculously).

This is because in a login process the hal-acl-tool sets acl permissions on that
files. But now hal-acl-tool is segfaulting, so no persmissions are set.
Comment 6 Lubomir Kundrak 2007-12-05 14:13:48 EST
(In reply to comment #2)
> I just noticed a suspected program looking in dmesg (on two different kernels):
> hal-acl-tool[3111]: segfault at 0ab66914 eip 00b80c4c esp bf8154f4 error 4
> lines like this pop up whenever I log in (be it the GNOME session or plain VT)
> with different "at" and "esp" addresses, but eip and error are the same. I've
> never seen hal-acl-tool segfaulting before (confirmed by grep on /var/log).

Are you able to get a stack trace?

Not being sure if this does something to do with kernel (comment #3), I don't
change the component -- just adding the HAL maintainer to CC.
Comment 7 Kevin R. Page 2007-12-05 14:36:09 EST
I don't see any hal-acl-tool messages, but my sound card has stopped working
after I updated only pilot-link from updates-testing.
Comment 8 Luis Villa 2007-12-05 14:55:48 EST
Seeing this too, since the same batch of updates.

[I'd mark this 'urgent', since sound is, you know, fairly critical, but I don't
have perms.]
Comment 9 Jason Farrell 2007-12-05 15:30:21 EST
This had been driving me mad too. Having to chmod a+rx /dev/snd/* before logging
in was getting old.

I can confirm that reverting back to pilot-link-0.12.2-7.fc8 from -9 in
updates-testing has fixed the problem.
Comment 10 Kevin R. Page 2007-12-05 18:24:10 EST
Reverting pilot-link fixes the soundcard for me too. Curiously, the newer
pilot-link package with the PolicyKit/udev permissions rule also seems to break
the fingerprint reader on my laptop - which works in gdm but not
gnome-screensaver, where it fails with an selinux alert:

Dec  5 21:29:51 localhost kernel: input: Virtual ThinkFinger Keyboard as
/class/input/input8
Dec  5 21:29:54 localhost setroubleshoot: #012    SELinux is preventing
/usr/bin/setfacl (hald_acl_t) "setattr" to <Unknown> (event_device_t).#
012     For complete SELinux messages. run sealert -l
bafd80da-bc89-4933-9818-85ea94d9fd42

The sealert raw audit messages were:

avc: denied { setattr } for comm=setfacl dev=tmpfs egid=0 euid=0
exe=/usr/bin/setfacl exit=-13 fsgid=0 fsuid=0 gid=0 items=0 name=event8
pid=7079scontext=system_u:system_r:hald_acl_t:s0 sgid=0
subj=system_u:system_r:hald_acl_t:s0 suid=0 tclass=chr_file
tcontext=system_u:object_r:event_device_t:s0 tty=(none) uid=0

With pilot-link reverted the fingerprint reader Just Works, and I just get:
Dec  5 23:12:30 localhost kernel: input: Virtual ThinkFinger Keyboard as
/class/input/input8
Comment 11 David Zeuthen 2007-12-05 19:52:44 EST
FWIW, I've filed a separate bug against pilot-link.
Comment 12 David Zeuthen 2007-12-05 19:54:02 EST
(In reply to comment #11)
> FWIW, I've filed a separate bug against pilot-link.

Which is bug 412921 but not everyone may be able to see it just yet as it's
marked as security...
Comment 13 Ivana Varekova 2007-12-06 06:57:53 EST
Fixed in pilot-link-0.12.2-10.
Comment 14 Luis Villa 2007-12-06 07:30:35 EST
I can confirm that it is fixed by pilot-link 0.12.2-10.
Comment 15 Peter Gückel 2008-02-24 13:30:05 EST
*** Bug 412581 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.