Bug 5113 - Permissin problem with Gnome and Esound
Permissin problem with Gnome and Esound
Product: Red Hat Linux
Classification: Retired
Component: esound (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Elliot Lee
Depends On:
  Show dependency treegraph
Reported: 1999-09-13 17:40 EDT by timnshan
Modified: 2008-05-01 11:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 1999-11-02 12:46:17 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description timnshan 1999-09-13 17:40:12 EDT
there's something weird about the way Gnome launches esd.
A little background to answer questions you may have:
This has been duplicated on other systems.
All users have been given rights to the necessary devices in
/dev/ and can successfully launch esd themselves (if it's
not already running of course)
Now to the issue.
When I log into Gnome as user1 (it can be any user actually)
and esd starts up, user1 can play sounds with no problem. If
I then log out and log in as user2 (or just open a terminal
and su user2) and try to play something through esd (like
x11amp) it says it could not open audio.
If user1 kills esd and relaunches it (or even if I have
user2 launch it in the previously mentioned terminal), it
then works for both users.
It seems that Gnome somehow launches it locked because it
also works for both users if user1 runs esdctl unlock as
opposed to killing and restarting esd.
The weird thing is, I even tried adding some start up
commands to the Gnome session manager to kill `pidof esd`
and then restart esd and it still had the same problem and I
had to esdctl unlock in order for both users to use esd. If
I only added kill `pidof esd` to the startup commands and
subsequently started esd from a terminal once logged in, it
works fine, without needing the esdctl unlock command.
For the time being, my work around is to add esdctl unlock
to everbody's Gnome session manager start up commands.

I hope this makes sense. I tried to consolidate the
different scenarios I came across while testing this out.
Anyway, is this how it's supposed to work? Is there a way
for Gnome to not start esd "locked" like this other than my
lame workaround?

------- Additional Comments From   09/16/99 20:29 -------
I don't know if this behavior you described is a bug, but here's
another workaround I found when I installed RHL6.0 on my ThinkPad
600E laptop. It comes from Thomas Hood
(http://jhunix.hcf.jhu.edu/~thood/tp600lnx.htm) and works fine for
me.  Add the following to the end of /etc/rc.d/rc.local file:
/usr/bin/esd -nobeeps -as 2 -public &
Thomas explains all the parameters in his document.  Good luck. Jorge
Martin (jorge.martin@eds.com)
Comment 1 Elliot Lee 1999-11-02 12:46:59 EST
I can't reproduce the specified behaviour (logout, login as another
user, try to use sound) in RHL 6.1. However, su'ing to another user
(e.g. trying to use sound as another user while one user is currently
using sound) will not work, because esd is strictly on a per-user
basis to avoid security problems.

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