On Tue, 2006-08-01 at 20:36 +0200, Isak Savo wrote: > As such, I don't really see why this thing would be impose any > security issues that didn't exist earlier. Lots of applications > already have a plug-in system, and to my knowledge, they also allow > extra plugins to be installed in $HOME (i.e. without root access). The > only thing that's changed is that it's suddenly possible to install > them without manually downloading and copying files to hidden > directories.
Related to this is something I was thinking about last night: some of the plugin systems aren't very nice for administrators to control. I was planning to file some bugs (after checking all the current apps), but it's related to this discussion. It would probably be good for apps with plugin systems to have a "don't allow per-user plugins" gconf key, so sysadmins can prevent users from running random code, and only use the allowed ones. Some applications (e.g. Gedit 2.14) have a single big "enabled plugins" key, which doesn't (afaik) give any options between "no admin control" and "no user control". It might be better to have separate keys for each plugin, like "plugins/$PLUGINNAME/enabled", which would allow admins to disallow (or make manditory, I guess) individual plugins, which allowing users to control those left unspecified. Cheers, James "Doc" Livingston -- "type in (cast) must be scalar; ANSI 3.3.4; page 39, lines 10-11 (I know you don't care, I'm just trying to annoy you)" -- MPW C error message _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
