Bug 553434 - lockdown in the keybinding plugin
lockdown in the keybinding plugin
Status: RESOLVED FIXED
Product: gnome-settings-daemon
Classification: Core
Component: plugins
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gnome-settings-daemon-maint
gnome-settings-daemon-maint
:
Depends on:
Blocks: 557989
  Show dependency tree
 
Reported: 2008-09-23 18:03 UTC by Matthias Clasen
Modified: 2008-11-11 05:31 UTC (History)
1 user (show)

See Also:
GNOME target: ---
GNOME version: ---


Attachments
keybinding-lockdown.patch (5.61 KB, patch)
2008-09-23 18:04 UTC, Matthias Clasen
none Details | Diff | Review
patch (3.76 KB, patch)
2008-10-19 22:03 UTC, Matthias Clasen
committed Details | Diff | Review

Description Matthias Clasen 2008-09-23 18:03:04 UTC
The keybinding plugin allows to associate arbitrary commandlines with key combinations and executes them. Thus it should be obeying the disable_command_line lockdown key.

I've written a patch that does so. I've also added some code to special-case
a commandline of the form "toggle-gconf-key /path/to/boolean/gconf/key". The
reason I want this handled internally is that we need to lockdown the commandline
handling in the gdm login session, but it would be great if we could use this
keybinding facility to implement accessibility hotkeys, by e.g. making
<Control><Alt>S toggle the /desktop/gnome/applications/at/screen_reader_enabled key. 

I'm open to rename toggle-gconf-key to something else - thats the name that my silly shell script for this purpose had.

Let me know what you think about this. I believe we need the lockdown part in any case.
Comment 1 Matthias Clasen 2008-09-23 18:04:08 UTC
Created attachment 119242 [details] [review]
keybinding-lockdown.patch
Comment 2 Jens Granseuer 2008-09-23 20:10:05 UTC
Shouldn't lockdown in this case rather mean "you can't define your own shortcuts" instead of "you can't use your shortcuts"?

Now, that might be somewhat harder to enforce (does GConf support read-only directories?), but I think it would make more sense, and also allow sys admins to define some system shortcuts if they so desire. Plus, it would make that ugly kludge unnecessary.
Comment 3 Matthias Clasen 2008-09-23 20:26:48 UTC
maybe so
Comment 4 Jens Granseuer 2008-09-26 18:16:54 UTC
I'll take that as a "yes". ;-)
Comment 5 Matthias Clasen 2008-09-26 22:38:05 UTC
The thing is, gconf doesn't have readonly directories :-(
So it won't work...
Comment 6 Jens Granseuer 2008-09-27 14:05:27 UTC
I suppose I'm going to argue that should be fixed, then.
Comment 7 Matthias Clasen 2008-10-19 22:01:02 UTC
Ok, lets try again. 

Since, as we found out, gconf doesn't have readonly directories, here is a patch that recognizes a /desktop/gnome/keybindings/allowed_keys key, which can be used to effectively ignore any extra keybindings beyond a fixed set. 

This lets us use some custom keybindings in a locked-down situation, without allowing the user to execute arbitrary commands via newly added shortcuts.
Comment 8 Matthias Clasen 2008-10-19 22:03:36 UTC
Created attachment 120890 [details] [review]
patch
Comment 9 Matthias Clasen 2008-11-09 16:40:03 UTC
Jens, any objection to this ? I'd really like to be able to turn on a11y hotkeys on the login screen to make our disabled users happy. One extra gconf key seems a small price to pay...
Comment 10 Jens Granseuer 2008-11-10 20:13:16 UTC
Well, I can't say I'm happy with it, but I don't have a better solution, either, short of improving GConf. I also don't necessarily agree that fixing GConf is counter-productive if the alternative is adding crappy workarounds to applications.

However, I guess I'll just hope we'll be able to rip it out again with whatever replacement we'll get for GConf.
Comment 11 Matthias Clasen 2008-11-11 05:31:07 UTC
Thanks, Jens. I've committed it and also added a schema for the allowed_keys gconf key.

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