Bug 259141 - wrong permissions on sound devices
wrong permissions on sound devices
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: hal (Show other bugs)
rawhide
All All
medium Severity low
: ---
: ---
Assigned To: David Zeuthen
Fedora Extras Quality Assurance
:
: 273981 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-08-28 02:51 EDT by Pierre Ossman
Modified: 2013-03-05 22:51 EST (History)
4 users (show)

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


Attachments (Terms of Use)
Contents of /etc/pam.d/login (f8test2) (687 bytes, text/plain)
2007-09-11 16:39 EDT, Chuck Ebbert
no flags Details

  None (edit)
Description Pierre Ossman 2007-08-28 02:51:00 EDT
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.
Comment 1 Tomas Mraz 2007-08-29 04:04:41 EDT
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::---
Comment 2 Pierre Ossman 2007-08-29 05:30:54 EDT
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).
Comment 3 David Zeuthen 2007-08-29 12:41:04 EDT
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.
Comment 4 Tomas Mraz 2007-09-01 15:49:25 EDT
*** Bug 273981 has been marked as a duplicate of this bug. ***
Comment 5 Chuck Ebbert 2007-09-10 18:33:54 EDT
Booting in runlevel 3 and attempting to start KDE gives "access denied" messages
when KDE starts up... did we really mean to break startx?
Comment 6 Tomas Mraz 2007-09-11 03:17:34 EDT
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?
Comment 7 Chuck Ebbert 2007-09-11 16:39:29 EDT
Created attachment 193001 [details]
Contents of /etc/pam.d/login (f8test2)
Comment 8 Chuck Ebbert 2007-09-11 16:49:55 EDT
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?
Comment 9 Chuck Ebbert 2007-09-11 18:53:24 EDT
If you do:

  $ sudo chmod o+rw /dev/dsp
  $ startx

Permissions get changed to "other::r--" when KDE starts.
Comment 10 Tomas Mraz 2007-09-12 03:03:01 EDT
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.
Comment 11 David Zeuthen 2007-09-18 16:05:05 EDT
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.
Comment 12 Tomas Mraz 2007-09-18 16:15:53 EDT
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.
Comment 13 David Zeuthen 2007-09-18 16:28:31 EDT
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.)

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