Bug 827655 - /dev/snd/seq: acl is missing the logged in user
/dev/snd/seq: acl is missing the logged in user
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: udev (Show other bugs)
17
All Linux
unspecified Severity high
: ---
: ---
Assigned To: udev-maint
Fedora Extras Quality Assurance
:
Depends On:
Blocks: FedoraAudio 836704
  Show dependency treegraph
 
Reported: 2012-06-02 00:07 EDT by Fernando Lopez-Lezcano
Modified: 2012-09-26 04:51 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-09-26 04:51:29 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Fernando Lopez-Lezcano 2012-06-02 00:07:33 EDT
Description of problem:
udev does not grant access to the logged in user to /dev/snd/seq (the ALSA MIDI sequencer interface). The acl does not include the logged in user as is the case for the pcm (ie: sound playback) interface. Other files in /dev/snd/* have the right acl. Users starting (for example) qjackctl get an error message stating that the ALSA sequencer device is not present (it is present and loaded but the acl is wrong). 

Version-Release number of selected component (if applicable):
Fedora 17's version of udev

How reproducible:
always

Steps to Reproduce:
1. start qjackctl
2. get error message
  
Actual results:
A user can't access the ALSA MIDI sequencer api without root fixing the acl. A showstopper for any MIDI related activity. 

Expected results:
No error message, access was working fine in Fedora 16 and eaelier
Comment 1 Kay Sievers 2012-06-02 09:52:00 EDT
Oh, the module isn't loaded, it's a "dead" device node, supposed to trigger the
loading of the module at access/open. "Dead" nodes have no dynamic ACL handling.

An ordianary user has no access rights to access it,  so it can not trigger the loading.

I have no good idea at this moment to make this work.

What you should be able to work around it, is:
  $ echo snd_seq > /etc/modules-load.d/seq.conf

which should force-load the module at bootup, and the ACL logic will find it
as a real device.
Comment 2 Fernando Lopez-Lezcano 2012-06-02 13:32:13 EDT
(In reply to comment #1)
> Oh, the module isn't loaded, it's a "dead" device node, supposed to trigger
> the
> loading of the module at access/open. "Dead" nodes have no dynamic ACL
> handling.
> 
> An ordianary user has no access rights to access it,  so it can not trigger
> the loading.
> 
> I have no good idea at this moment to make this work.
> 
> What you should be able to work around it, is:
>   $ echo snd_seq > /etc/modules-load.d/seq.conf
> 
> which should force-load the module at bootup, and the ACL logic will find it
> as a real device.

Hmmm, I could swear I did a chmod 666 and it worked, probably that is enough to trigger loading?)...

We have to find how this was done in Fedora 16, this was working before and is not working now, it is a regression that should be fixed. This should be part of whatever loads the sound modules, right? If a soundcard is found and it has a midi interface snd-seq should be loaded.
Comment 3 Fernando Lopez-Lezcano 2012-06-02 15:33:32 EDT
(In reply to comment #1)
> Oh, the module isn't loaded, it's a "dead" device node, supposed to trigger
> the
> loading of the module at access/open. "Dead" nodes have no dynamic ACL
> handling.

Here, right?:

/lib/udev/rules.d/50-udev-default.rules:  OPTIONS+="static_node=snd/seq", OPTIONS+="static_node=snd/timer"

Hmmm, but that is the same in fc16 and fc17
Aha, in fc16:

/etc/modprobe.d/dist-alsa.conf:

install snd-pcm /sbin/modprobe --ignore-install snd-pcm && /sbin/modprobe snd-seq

In Fedora 16 this was part of module-init-tools but in Fedora 17 that package is obsoleted by "kmod" which has no rules included. 

I guess we could do this in two ways:
a) we always load snd-seq (as suggested in comment #1)
b) we load snd-seq only if a soundcard exists in the system

I would be inclined to go with a) as you strictly don't need a working soundcard to do MIDI processing or start a MIDI aware program. 

In which case: who (which package) should take care of this? kmod?? alsa-lib? Looks like alsa-lib to me as if that is not installed we can't use the ALSA sequencer interface anyway (if we do add this to alsa-lib that we have to have a post-install script that loads snd-seq anyway as it can't be dynamic).
Comment 4 Fernando Lopez-Lezcano 2012-06-02 15:48:07 EDT
(In reply to comment #3)
> (In reply to comment #1)
> > Oh, the module isn't loaded, it's a "dead" device node, supposed to trigger
> > the
> > loading of the module at access/open. "Dead" nodes have no dynamic ACL
> > handling.
> 
> Here, right?:
> 
> /lib/udev/rules.d/50-udev-default.rules:  OPTIONS+="static_node=snd/seq",
> OPTIONS+="static_node=snd/timer"
> 
> Hmmm, but that is the same in fc16 and fc17
> Aha, in fc16:
> 
> /etc/modprobe.d/dist-alsa.conf:
> 
> install snd-pcm /sbin/modprobe --ignore-install snd-pcm && /sbin/modprobe
> snd-seq
> 
> In Fedora 16 this was part of module-init-tools but in Fedora 17 that
> package is obsoleted by "kmod" which has no rules included. 
> 
> I guess we could do this in two ways:
> a) we always load snd-seq (as suggested in comment #1)
> b) we load snd-seq only if a soundcard exists in the system
> 
> I would be inclined to go with a) as you strictly don't need a working
> soundcard to do MIDI processing or start a MIDI aware program. 
> 
> In which case: who (which package) should take care of this? kmod??
> alsa-lib? Looks like alsa-lib to me as if that is not installed we can't use
> the ALSA sequencer interface anyway (if we do add this to alsa-lib that we
> have to have a post-install script that loads snd-seq anyway as it can't be
> dynamic).

Maybe here? (part of alsa-lib):

more /usr/share/alsa/alsa.conf.d/README
You can place files named *.conf in this folder and they will be processed
when initialising alsa-lib.
Comment 5 Orcan Ogetbil 2012-06-04 20:51:32 EDT
(In reply to comment #2)
> (In reply to comment #1)
> 
> Hmmm, I could swear I did a chmod 666 and it worked, probably that is enough
> to trigger loading?)...
> 

I verify that chmod 666 works. At least it takes things one step further. I have similar problems with /dev/rtc which is a symlink to /dev/rtc0. I had to chmod 666 /dev/rtc0 as well. Then I had to bump /sys/class/rtc/rtc0/max_user_freq from 64 to 1024 to get things working. The question is, how to do all these things properly, with minimal user intervention.
Comment 6 Harald Hoyer 2012-06-05 05:31:57 EDT
(In reply to comment #5)
> (In reply to comment #2)
> > (In reply to comment #1)
> > 
> > Hmmm, I could swear I did a chmod 666 and it worked, probably that is enough
> > to trigger loading?)...
> > 
> 
> I verify that chmod 666 works. At least it takes things one step further. I
> have similar problems with /dev/rtc which is a symlink to /dev/rtc0. I had
> to chmod 666 /dev/rtc0 as well. Then I had to bump
> /sys/class/rtc/rtc0/max_user_freq from 64 to 1024 to get things working. The
> question is, how to do all these things properly, with minimal user
> intervention.

Why on earth do you want /dev/rtc to be world writeable???
Comment 7 Orcan Ogetbil 2012-06-05 08:27:14 EDT
Sorry, I have to make a correction. It is sufficient to have /dev/rtc as 444. However it is 600 in the default Fedora 17 installation.
Comment 8 Fernando Lopez-Lezcano 2012-06-06 14:55:45 EDT
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #1)
> > > Oh, the module isn't loaded, it's a "dead" device node, supposed to trigger
> > > the
> > > loading of the module at access/open. "Dead" nodes have no dynamic ACL
> > > handling.
> > 
> > Here, right?:
> > 
> > /lib/udev/rules.d/50-udev-default.rules:  OPTIONS+="static_node=snd/seq",
> > OPTIONS+="static_node=snd/timer"
> > 
> > Hmmm, but that is the same in fc16 and fc17
> > Aha, in fc16:
> > 
> > /etc/modprobe.d/dist-alsa.conf:
> > 
> > install snd-pcm /sbin/modprobe --ignore-install snd-pcm && /sbin/modprobe
> > snd-seq
> > 
> > In Fedora 16 this was part of module-init-tools but in Fedora 17 that
> > package is obsoleted by "kmod" which has no rules included. 
> > 
> > I guess we could do this in two ways:
> > a) we always load snd-seq (as suggested in comment #1)
> > b) we load snd-seq only if a soundcard exists in the system
> > 
> > I would be inclined to go with a) as you strictly don't need a working
> > soundcard to do MIDI processing or start a MIDI aware program. 
> > 
> > In which case: who (which package) should take care of this? kmod??
> > alsa-lib? Looks like alsa-lib to me as if that is not installed we can't use
> > the ALSA sequencer interface anyway (if we do add this to alsa-lib that we
> > have to have a post-install script that loads snd-seq anyway as it can't be
> > dynamic).
> 
> Maybe here? (part of alsa-lib):
> 
> more /usr/share/alsa/alsa.conf.d/README
> You can place files named *.conf in this folder and they will be processed
> when initialising alsa-lib.

If this is not going to or cannot be fixed in udev, what is the best way to move forward?

Should I file a new bug against a different component? Should this bug be moved to a different component? Alsa-lib perhaps?
Comment 9 Orcan Ogetbil 2012-06-06 21:17:07 EDT
I would say we should move this to some other component, kernel or alsa-lib I suppose.
Comment 10 Fedora Update System 2012-09-07 08:22:54 EDT
python-alsa-1.0.26-1.fc17, alsa-plugins-1.0.26-1.fc17, alsa-tools-1.0.26.1-1.fc17, alsa-utils-1.0.26-1.fc17, alsa-lib-1.0.26-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/python-alsa-1.0.26-1.fc17,alsa-plugins-1.0.26-1.fc17,alsa-tools-1.0.26.1-1.fc17,alsa-utils-1.0.26-1.fc17,alsa-lib-1.0.26-1.fc17
Comment 11 Fedora Update System 2012-09-08 22:52:27 EDT
Package python-alsa-1.0.26-1.fc17, alsa-plugins-1.0.26-1.fc17, alsa-tools-1.0.26.1-1.fc17, alsa-utils-1.0.26-1.fc17, alsa-lib-1.0.26-1.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing python-alsa-1.0.26-1.fc17 alsa-plugins-1.0.26-1.fc17 alsa-tools-1.0.26.1-1.fc17 alsa-utils-1.0.26-1.fc17 alsa-lib-1.0.26-1.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-13658/python-alsa-1.0.26-1.fc17,alsa-plugins-1.0.26-1.fc17,alsa-tools-1.0.26.1-1.fc17,alsa-utils-1.0.26-1.fc17,alsa-lib-1.0.26-1.fc17
then log in and leave karma (feedback).
Comment 12 Fedora Update System 2012-09-26 04:51:29 EDT
python-alsa-1.0.26-1.fc17, alsa-plugins-1.0.26-1.fc17, alsa-tools-1.0.26.1-1.fc17, alsa-utils-1.0.26-1.fc17, alsa-lib-1.0.26-1.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

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