This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 134327 - Only one user can access devices
Only one user can access devices
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: pam (Show other bugs)
3
All Linux
medium Severity high
: ---
: ---
Assigned To: Tomas Mraz
:
Depends On:
Blocks: FC3Blocker 135718
  Show dependency treegraph
 
Reported: 2004-10-01 09:27 EDT by Paul F. Johnson
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-10-14 10:42:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Paul F. Johnson 2004-10-01 09:27:58 EDT
Description of problem:
Shared devices (such as scanner and sound) can only be used by one
user. All others are unable to access them.

Version-Release number of selected component (if applicable):
0.77-60

How reproducible:
Always

Steps to Reproduce:
1. Login as one user, soundcard is fine. Logout
2. Login as another user, soundcard is blocked

This also applies to scanners and other devices
  
Actual results:
Sound and scanner are blocked.

Expected results:
Sound and scanner should work for any user

Additional info:
The first user to access the soundcard takes control of the card. The
old way I used to use was to make the soundcard and scanner a member
of their own groups and then make all users members of (say) the
soundcard group. That used to work. It doesn't now.

I would consider this inability as a blocker, but have not passed it
to the developers list.
Comment 1 Bill Nottingham 2004-10-01 19:51:08 EDT
It should be reset on logout so the second user can have access.
Comment 2 Bill Nottingham 2004-10-01 19:56:41 EDT
I can't reproduce this here. With two users, 'bob', and 'joe'.

bob logs in on the console -> bob owns the audio devices.
bob logs out. devices are reset to root.
joe logs in on the console -> joe owns the audio devices.
joe logs out. devices are reset to root.
Comment 3 Paul F. Johnson 2004-10-02 03:45:56 EDT
Not happening here on either the fresh FC3t2 box or the updated from FC2.

paul logs into X and into console -> paul owns sound, root owns scanner
paul logs out of X
bev logs into X -> !bev owns sound, root owns scanner

The permissions are not being correctly set
Comment 4 Bill Nottingham 2004-10-03 23:16:56 EDT
paul is still logged in on console, ergo, permissions not reset.
Comment 5 Paul F. Johnson 2004-10-04 02:26:09 EDT
if paul is not logged in as console, only logged into an X session,
logs out, bev logs into an X session, permissions not reset - she
still can't access the scanner (which paul couldn't either!) or the
soundcard.

Ergo, permissions not reset
Comment 6 Tomas Mraz 2004-10-08 07:48:29 EDT
I think there could be some problem with our udev setup (however I'm
not sure).

Paul: you've written in comment #3 that bev after logging into X owns
sound, or I misunderstood you?

Comment 7 Paul F. Johnson 2004-10-08 08:32:59 EDT
Whoever logs in first gets the soundcard. It doesn't matter if they
log in as console only or into X. The permissions are not being reset
when the user logs out.

If bev logs in first, she gets the permissions for the soundcard. If
richard logs in first, he gets the permissions, if I log in first, I
get the permissions. These are then *not* reset for the next user on
logging out.

It may be related, but if a user is logged in more than once (for
instance, I may be logged in on 4 terminals at once), then they logout
of X, the next person won't be able to enable sound due to the other
user being still logged in on the terminals. Can things be made that
such items as sound, scanners etc are made universal irrespective of
the number of times someone is logged in?
Comment 8 Bill Nottingham 2004-10-08 12:05:09 EDT
The first behavior is a bug, the second behavior is expected, just FYI.
Comment 9 Paul F. Johnson 2004-10-08 12:44:25 EDT
I know the second one is expect, it's a pain in the backside though -
especially when I'm using a terminal to do lots of things in the
background...
Comment 10 Paul F. Johnson 2004-10-09 11:43:24 EDT
Just as a test. I've rebooted and logged in as another user, xmms is
automatically started on loggin in. I log out and then log in as
myself. Both /dev/dsp and /dev/dsp1 are owned by bev.root. If I then
chown paul.root /dev/dsp and chown paul.root /dev/dsp1, xmms still
reports that the sound card is blocked. However, if I then say to use
the OSS driver, sound is restored.

This now leads me to suspect both Alsa and pam are at fault here. This
suspicion is further raised in that xine will play audio despite xmms
saying the sound card is blocked (audio on xine goes through OSS
rather than anything else).

At the time, I was not logged into any consoles - one user at a time
Comment 11 Tomas Mraz 2004-10-14 10:42:06 EDT
With the latest udev package I don't see anything like you reported.
Older packages were probably the source of the bug.
You can try to upgrade udev (you should upgrade kernel, mkinitrd and
initscripts as well) and verify if it's fixed.

Of course the second behaviour in comment #7 is WONTFIX for the FC3.
You can open an enhancement request after that.

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