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 ACLs assigned. The output should look like: getfacl /dev/dsp getfacl: Removing leading '/' from absolute path names # file: dev/dsp # owner: root # group: root user::rw- user:gdm:rw- user:mraz:rw- group::rw- mask::rw- other::---
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 startup. 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 $ startx 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.)