After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 524526 - Honor a key to disable all url handlers
Honor a key to disable all url handlers
Status: RESOLVED OBSOLETE
Product: gvfs
Classification: Core
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gvfs-maint
gvfs-maint
Depends on: 524522
Blocks:
 
 
Reported: 2008-03-26 18:42 UTC by William Jon McCann
Modified: 2014-11-05 10:56 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch (2.40 KB, patch)
2008-03-26 19:58 UTC, William Jon McCann
none Details | Review

Description William Jon McCann 2008-03-26 18:42:32 UTC
AFAICT, currently, if we want to lock-down the desktop's handling of URLs we
have to try to figure out all the possible keys to lockdown via
/desktop/gnome/url-handlers/*.  It would be useful to have a
/desktop/gnome/lockdown/disable_url_handlers key that would disable them all.
Comment 1 William Jon McCann 2008-03-26 19:58:59 UTC
Created attachment 108086 [details] [review]
patch

Simply returning NULL from get_default_for_uri_scheme() doesn't work because in that case g_file_query_default_handler() will fallback to g_file_query_info().
Comment 2 Alexander Larsson 2008-03-27 09:24:51 UTC
I don't understand why the fallback is a problem? Do you really want nautilus to never be able to open any files you click on? Thats what the result of this patch is.
Comment 3 William Jon McCann 2008-03-27 12:45:22 UTC
Hi Alex.

Yes, that's the desired behavior.  You'd use this when locking down a kiosk or in our case the GDM greeter.

So, it is probably a very rare occasion that you'd want to set disable_url_handlers=true but when you do you probably don't want gio to ignore it.

In these cases you don't want nautilus to run at all.  You also want to lock down gvfs-open, and any gio/gvfs enabled application.

With the fallback it seems that unlike gnome-vfs there really isn't any way to lockdown a url-handler at all.  AFAICT, even setting the specific url-handler enabled=false in mandatory policy isn't honored.  But that wouldn't be a good enough solution on its own because there are no constraints on the possible handlers.  Maybe there is something I'm missing?
Comment 4 Alexander Larsson 2008-03-28 09:12:28 UTC
I wasn't aware of the per-url-type enabled key. We should handle that too.

There are two types of settings for app launching
uri scheme => app
mime type => app

The helper code in e.g. g_file_query_default_handler() [which is used by g_app_info_launch_default_for_uri()]. First look at the uri handler and then at the mime type. This is why I thought it was kinda weird that disable_url_handlers would also disable mime type handlers.

Now, it seems you're really out to do something else, i.e. completely disable all app mappings. I think that is better handled by having both the uri scheme => app and mime type => app mappings return NULL. Otherwise things that try to launch a file that manually codes things to not look at the uri scheme mapping will still work. Of course, i still think the name disable_url_handlers is kinda weird for this, its more like disable_application_handlers.
Comment 5 William Jon McCann 2008-03-31 23:23:15 UTC
Thanks for the comments Alex.  Indeed, locking down mime type handlers would be desirable in this case too.  So correct me if I'm wrong, but we would need to be able to hook into g_app_info_get_default_for_type() to check GConf.  Would that require adding something like the following to GDesktopAppInfoLookupIface:

  GAppInfo * (*get_default_for_type) (GDesktopAppInfoLookup *lookup,
				      const char            *mime_type);

Is that something we're allowed to do at this point?  What do you think?  Thanks.
Comment 6 Matthias Clasen 2008-08-15 21:50:21 UTC
Did we ever fully resolve this, Jon ?
Comment 7 Ondrej Holy 2014-11-05 10:56:37 UTC
Marking as obsolete since this is an old bug and the code was moved into the glib long time ago.