GNOME Bugzilla – Bug 662220
would like way to whitelist plugins
Last modified: 2012-11-15 18:03:40 UTC
gdm only starts a subset of the gnome-settings-daemon plugins. Right now we have a hard coded list, but if g-s-d gains a new one it will get started "automatically" without getting vetted for the login screen first. It would be good if there was a whitelist gsettings key that can optionally limit the list of plugins to a pre-defined subset of the available ones.
Agreed.
Alternatively plugins could register themselves as “safe” (meaning safe to run as anonymous user), and a single boolean key could exclude all “unsafe“ plugins at once.
Created attachment 228869 [details] [review] main: Add settings key to whitelist plugins Rather than having gdm load all the new plugins by default, especially when gnome-settings-daemon gets updated and gdm doesn't, keep a list of whitelisted plugins. Only those can be enabled, others will be unknown and ignored. By default, all plugins are whitelisted.
(note, not run-time tested)
Review of attachment 228869 [details] [review]: Looks good. Will do some testing and report back. ::: gnome-settings-daemon/gnome-settings-manager.c @@ +208,3 @@ + if (whitelist == NULL || + whitelist[0] == NULL || + g_strcmp0 (whitelist[0], "all") == 0) can just use strcmp here since you already check for NULL. Alternatively, can drop the whitelist[0] check for NULL @@ +409,1 @@ So this definitely won't work for changes at runtime. I guess that's actually a good thing though. We don't want to start loading a new plugin in an existing process when the old version of the plugin hasn't been made "safe" yet.
(In reply to comment #5) > Review of attachment 228869 [details] [review]: > > Looks good. Will do some testing and report back. > > ::: gnome-settings-daemon/gnome-settings-manager.c > @@ +208,3 @@ > + if (whitelist == NULL || > + whitelist[0] == NULL || > + g_strcmp0 (whitelist[0], "all") == 0) > > can just use strcmp here since you already check for NULL. Alternatively, can > drop the whitelist[0] check for NULL Noted. > So this definitely won't work for changes at runtime. I guess that's actually > a good thing though. We don't want to start loading a new plugin in an > existing process when the old version of the plugin hasn't been made "safe" > yet. Yep. As documented in the schema. I don't think it makes any sort of sense otherwise.
Also, you inserted a bunch of tabs into a file that's using spaces. Tested things, though, and after I spell whitelisted right (ahem) it works great! thanks, much
Created attachment 228938 [details] [review] data: use new g-s-d's plugin whitelist GDM tries to manually turn off unvetted or unwanted gnome-settings-daemon plugins explicitly. This requires close coordination between gdm and gnome-settings-daemon to make sure the lists down get out of sync. gnome-settings-daemon now supports having an explicit whitelist, which is a much more robust way to handle our needs. This commit changes GDM's dconf configuration to use the new whitelist setting, instead of expliciting turning off each unwanted plugin.
(i've put the GDM half as attachment 228938 [details] [review] for safe keeping here until the settings-daemon stuff lands)
Attachment 228869 [details] pushed as 1dc03f2 - main: Add settings key to whitelist plugins
Comment on attachment 228938 [details] [review] data: use new g-s-d's plugin whitelist Attachment 228938 [details] pushed as 4571d48 - data: use new g-s-d's plugin whitelist