Red Hat Bugzilla – Bug 259141
wrong permissions on sound devices
Last modified: 2013-03-05 22:51:54 EST
A recent upgrade made sound non-functional on the desktop. The permission
modifications in /etc/security/console.perms.d have been removed, resulting in
the sound device nodes being owned by root.
Sound devices should be handled by HAL now. Note that the permissions are set by
using ACLs so the device nodes are owned by root but they should get addtitional
The output should look like:
getfacl: Removing leading '/' from absolute path names
# file: dev/dsp
# owner: root
# group: root
I understand the point of the extra ACLs, but why can't you keep the old
behaviour as well? Then you avoid adding the requirement on
CONFIG_TMPFS_POSIX_ACL for the common case (one user at a time).
The new behavior is that you only have access to the (sound) device when your
session is actually active.
This is to prevent an inactive session using the sound device to capture audio
and thereby spy on the active session (think campus setting). Of course we still
need revoke() to do this properly but this change is part of that puzzle.
(I put sound in parenthesis because it also applies to other kinds of devices,
e.g. webcams etc.)
Closing this as NOTABUG.
*** Bug 273981 has been marked as a duplicate of this bug. ***
Booting in runlevel 3 and attempting to start KDE gives "access denied" messages
when KDE starts up... did we really mean to break startx?
Are the ACLs on your machine assigned? What's the contents of your
/etc/pam.d/login? Are there any messages in /var/log/secure?
Created attachment 193001 [details]
Contents of /etc/pam.d/login (f8test2)
The ACL "cebbert:rw-" is there when I log in in console mode and look before
starting X, but then it disappears; when looking from a console window in X it's
gone and the only named user level acl is "gdm:rw-"
There are no messages in /var/log/secure, and no audit messages, but the KDE
sound system definitely says it is getting access denied(write) on /dev/dsp on
I have DISPLAYMANAGER="KDE" in /etc/sysconfig/desktop, but that probably makes
no difference when starting from runlevel 3?
If you do:
$ sudo chmod o+rw /dev/dsp
Permissions get changed to "other::r--" when KDE starts.
That seems like serious problem in design of ConsoleKit - the startx shouldn't
mess up the permissions. Please open a new bug report for this against ConsoleKit.
startx should indeed result in ACL's being added; think of it; it's just a new
session that is started much like when you log in from gdm. FWIW, this works
fine for me and we're tracking Chuck's problem in bug 278851.
Well added maybe, but definitely not removed. The user should have the ACLs
already from the text console login or why not? startx might be seen as
additional session of the same user so the permissions should stay the same.
Technically a session switch does occur and ACL's can change if your session
goes from inactive to active. Of course, if the sessions have the same user this
is not an issue and nothing changes.
This bug only happens because of, for some reason, Chuck isn't getting a session
created in ConsoleKit when using startx. Hence we switch to a session that isn't
registered with ConsoleKit and hence the switch away from the session on VT1
causes the removal of the ACL's. That is tracked in bug 278851.
(It is, btw, expected behavior. If I log in as testuser on VT1 in runlevel 3 and
then do "su - davidz; startx" then ACL's are indeed removed from testuser when
the session starts. If you switch back to VT1 the ACL's will be removed from
davidz and given back to testuser.)