Bug 361501 - Any user can disable managed power button functionality
Summary: Any user can disable managed power button functionality
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: acpid
Version: 7
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Zdenek Prikryl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-11-01 11:41 UTC by Alan Cox
Modified: 2008-01-24 22:02 UTC (History)
2 users (show)

Fixed In Version: 1.0.6-5.fc8
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-01-24 22:02:17 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Alan Cox 2007-11-01 11:41:07 UTC
acpid ships with a script which does the following:

event=button/power.*
action=/bin/ps awwux | /bin/grep gnome-power-manager | /bin/grep -qv grep || /sb
in/shutdown -h now


Any user running a script of their own called gnome-power-manager left in the
background confuses the script because it checks via ps, not properly by some
kind of pid/lock file check with the power mangler itself.

Comment 1 Zdenek Prikryl 2007-11-06 09:43:50 UTC
Hello,
gnome-power-manager does not create any pid/lock file. So, if we want to use
another way, we have to use D-BUS.

Then the script would look like this:

event=button/power.*
action=/bin/dbus-send  --dest=org.freedesktop.DBus /org/freedesktop/DBus
--print-reply org.freedesktop.DBus.ListNames | grep org.gnome.PowerManager ||
/sbin/shutdown -h now

But anyone can write his own script/application which can have same name (then
ps check will fail) or which can register same name in a d-bus (then dbus check
will fail). Even if a gnome-power-manager used pid/lock file, then anyone would
write application, which would use same pid/lock file too.

So, the question is, what is sufficient control.

Comment 2 Zdenek Prikryl 2007-11-06 10:34:17 UTC
A solution with D-BUS is more complicated. The script is ran by root, so one has
to get information about a DBUS_SESSION_BUS_ADDRESS. This variable is stored in
/proc/*/environ, so one has to use ps anyway.

Comment 3 Alan Cox 2007-11-23 15:15:52 UTC
It still needs fixing as its a DoS issue

Reopening


Comment 4 Alan Cox 2007-11-23 15:20:49 UTC
Two observations

1.  If you fix gnome-power-mangler to use a lock file then you can sort the
problem trivially
2.  Failing that the dbus method is still a good one although you'd need a way
to get the dbus session info for the current desktop user.
3.  Cleaner still would be for gnome-power-mangler and the button script to
share a named pipe or similar resources

Letting a user *choose* to intercept the power button by dbus or other means is
good, the problem with this bug is I can intercept it when I'm not the live
desktop session.

So I would either fix gnome power manager or wrap it in a bit of code which
writes the pid somewhere then uses exec to run the g-p-m daemon thus giving you
a reliable pid to also match in your grep along with the name.



Comment 5 David Zeuthen 2007-11-28 16:08:38 UTC
(In reply to comment #0)
> Any user running a script of their own called gnome-power-manager left in the
> background confuses the script because it checks via ps, not properly by some
> kind of pid/lock file check with the power mangler itself.

<annoyed>
Wow, you're so cool calling it mangler instead of manager. Let's all just rant
and use language like that so we can be as cool as Alan.
</annoyed>

Now, on a more serious note, keep in mind you may have multiple copies of g-p-m
running; one for each desktop session (this f-u-s etc.). So at least doing pid
files is not going to work...


Comment 6 David Zeuthen 2007-11-28 16:09:41 UTC
(Also keep in mind any solution like this should work for kpowersave and other
desktops)

Comment 7 David Zeuthen 2007-11-28 16:10:43 UTC
One way to do this is to check with ConsoleKit whether there are any login
sessions. Probably ck-list-sessions can do this (patches welcome to make it do
what you want); alternatively dbus-send might be another option.

Comment 8 David Zeuthen 2007-11-28 16:14:08 UTC
Just for reference, here are the ConsoleKit docs

http://people.freedesktop.org/~mccann/doc/ConsoleKit/ConsoleKit.html

They're also in the ConsoleKit-docs package FWIW.

Comment 9 Alan Cox 2007-11-28 17:09:06 UTC
<chill>
I habitually use -mangler for all sorts of things that are -manager, my own code
included. That wasn't even done intentionally
</chill>

If you hve multiple clients you can do pid files, they just have to hold
multiple entries.  ConsoleKit looks perfect here however as it will tell you if
the uid of the supposed 'gnome power manager' matches the current session and
that tells you if the ps return is a real power manager (and a user who has
their own personal gnome-power-manager and is on the console is their own problem).

Not sure if that means you want a "has power manager'  for sessions whether k or
gnome-power-manager ?


Comment 10 Zdenek Prikryl 2007-12-19 13:47:35 UTC
I'm not sure, how I'd recognize real g-p-m.
Alan, you wrote that ck tells me the uid of the supposed g-p-m. So when I
execute 'ck-list-sessions', I'll get a list of sessions and I can grep a uid of
active session. (for example 500).
Then I execute 'ps aux' I'll get list of processes in which can be g-p-m and
then I can match uid of active session and uid of g-p-m. That is fine.
But if create a script called g-p-m and I'll execute it, then the uid of this
script will match the uid of active session.

So, I don't see any advantages or improvements if I solve this bug in this way.

Furthermore, as David wrote, we need a solution, which resolve this for any
other desktops, mainly for kde.

Comment 11 Alan Cox 2007-12-19 16:50:10 UTC
If you create a script called g-p-m and you are the desktop active user you can
only mess with your own user experience - maybe even usefully.

If you are not the active desktop it is important you don't get to mess with
anyone elses.


Comment 12 Zdenek Prikryl 2007-12-19 16:58:57 UTC
Ok, in this point of view, the solution described above is useful.

Comment 13 Fedora Update System 2008-01-24 21:59:46 UTC
acpid-1.0.4-9.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 14 Fedora Update System 2008-01-24 22:02:13 UTC
acpid-1.0.6-5.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.


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