|
Home > Archive > Debian Developers > July 2004 > Permissions on power management device nodes?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Permissions on power management device nodes?
|
|
| Colin Watson 2004-07-28, 6:23 pm |
| Recent versions of GNOME complain at login time that non-root users
can't write to /dev/pmu. I initially thought "yes, good, that's right,
now stop complaining", but apparently things like the GNOME keybindings
for the volume control and the suspend function of the battery applet
need it.
This got me wondering what the correct group for power management device
nodes would be. None of the current global static allocations seem
appropriate (audio and video are closest, but still aren't good
matches), and I was thinking of creating a new one in base-passwd so
that makedev, udev, and so on can use it conveniently. I don't want to
do this without talking with the various power management maintainers,
though, so what seems like a sensible set of people are CCed.
Are there any precedents on other systems that we should be borrowing?
If not, does anyone have any suggestions, or reasons why the current
root:root 0660 arrangement is best left as it is?
Thanks,
--
Colin Watson [cjwatson@flatline.org.uk]
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Bastian Blank 2004-07-28, 6:23 pm |
| On Tue, Jul 27, 2004 at 01:59:51AM +0100, Colin Watson wrote:
> Recent versions of GNOME complain at login time that non-root users
> can't write to /dev/pmu. I initially thought "yes, good, that's right,
> now stop complaining", but apparently things like the GNOME keybindings
> for the volume control and the suspend function of the battery applet
> need it.
Nope, volume control is completely different, suspend is able to use
pmud.
The direct access of the device just blocks pmud and makes the other
tools disfunctional.
Bastian
--
Emotions are alien to me. I'm a scientist.
-- Spock, "This Side of Paradise", stardate 3417.3
| |
| Colin Watson 2004-07-28, 6:23 pm |
| On Tue, Jul 27, 2004 at 09:18:50AM +0200, Bastian Blank wrote:
> On Tue, Jul 27, 2004 at 01:59:51AM +0100, Colin Watson wrote:
>
> Nope, volume control is completely different, suspend is able to use
> pmud.
>
> The direct access of the device just blocks pmud and makes the other
> tools disfunctional.
So this is all just a plain bug in GNOME?
--
Colin Watson [cjwatson@flatline.org.uk]
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Bastian Blank 2004-07-28, 6:23 pm |
| On Tue, Jul 27, 2004 at 01:05:18PM +0100, Colin Watson wrote:
> So this is all just a plain bug in GNOME?
I think so.
Bastian
--
Insufficient facts always invite danger.
-- Spock, "Space Seed", stardate 3141.9
| |
| Michael Schmitz 2004-07-28, 6:23 pm |
| > > > Recent versions of GNOME complain at login time that non-root users
>
> So this is all just a plain bug in GNOME?
Looks like it, from my POV. /dev/pmu can't be shared it seems. So gnome
should not even try to touch it. Implementing concurrent access to the PMU
may be possible at kernel level (taking proper care to lock out write
access by multiple processes), with such a measure we could permit
Gnome to play with the PMU as well. Not for snoozing, that should be
handled through pmud or equivalent. And for reading power state there's
/proc/apm. IOW, I don't understand what Gnome needs to access /dev/pmu
for.
Michael
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Carlos Perelló Marín 2004-07-28, 6:23 pm |
| On Tue, 2004-07-27 at 15:24 +0200, Michael Schmitz wrote:
[...]
>
> Looks like it, from my POV. /dev/pmu can't be shared it seems. So gnome
> should not even try to touch it. Implementing concurrent access to the PMU
> may be possible at kernel level (taking proper care to lock out write
> access by multiple processes), with such a measure we could permit
> Gnome to play with the PMU as well. Not for snoozing, that should be
> handled through pmud or equivalent. And for reading power state there's
> /proc/apm. IOW, I don't understand what Gnome needs to access /dev/pmu
> for.
I think it tries to access it to control the backlight from the Apple's
computer. It comes from ACME and If I remember it right is what ACME
needed to control it.
Cheers.
>
> Michael
>
>
--
Carlos Perelló Marín
Debian GNU/Linux Sid (PowerPC)
Linux Registered User #121232
mailto:carlos@pemas.net || mailto:carlos@gnome.org
http://carlos.pemas.net
Valencia - Spain
|
|
|
|
|