Bug 1214978 - Not installing redshift.desktop file breaks geoclue authorization
Summary: Not installing redshift.desktop file breaks geoclue authorization
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: redshift
Version: 22
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Miloš Komarčević
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-04-24 01:46 UTC by kxra
Modified: 2016-02-17 04:55 UTC (History)
16 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2015-11-30 21:20:40 UTC


Attachments (Terms of Use)

Description kxra 2015-04-24 01:46:36 UTC
Description of problem: After installing from the software center, Redshift will not run due to a lack of permissions in Geoclue.conf

Version-Release number of selected component (if applicable):


How reproducible:

100%

Steps to Reproduce:
1. Install redshift-gtk
2. Run it
3. Observe

Actual results:

It returns the following error: 

«Trying location provider `geoclue2'...
Unable to start GeoClue client: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Access denied.»

Expected results:

Redshift runs.

Additional info:

Comment 1 kxra 2015-04-24 01:47:02 UTC
Here is a line that allows Redshift to work: https://github.com/jonls/redshift/issues/158#issuecomment-71329118

Comment 2 Peter Robinson 2015-04-24 09:51:36 UTC
Wrong geoclue

Comment 3 Zeeshan Ali 2015-05-05 17:30:17 UTC
(In reply to kxra from comment #1)
> Here is a line that allows Redshift to work:
> https://github.com/jonls/redshift/issues/158#issuecomment-71329118

That line should not be needed. I recall I fixed something regarding this not so long ago. Could you please make sure you have the latest geoclue package (i-e 2.2.0)?

Comment 4 Zeeshan Ali 2015-05-05 17:31:41 UTC
Just FYI, geoclue was only updated very recently so please do reproduce again just to ensure that issue really is reproducible against latest geoclue.

Comment 5 Chad Versace 2015-05-19 16:54:49 UTC
I can reproduce with the latest geoclue2 package in Fedora 22.

  geoclue2-2.2.0-1.fc22.x86_64

Redshift produces the error messages below, then immediately dies.

    [chadv@aplomb ~]$ redshift -o |& tee redshift.log
    Trying location provider `geoclue2'...
    Using provider `geoclue2'.
    Unable to start GeoClue client: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Access denied.
    Unable to connect to GeoClue.
    Unable to get location from provider.
    [chadv@aplomb ~]$
                          
On my system, /etc/geoclue/geoclue.conf is the unmodified provided by the geoclue2 package.

    [root@aplomb etc]# md5sum /etc/geoclue/geoclue.conf 
    d63a46c3d7bb9ba5393f92f781cdddbc  /etc/geoclue/geoclue.conf

I confirmed that adding these lines to geoclue.conf, as described in the Github issue [1], fixes the issue:

    [redshift]
    allowed=true
    system=false
    users=

[1] https://github.com/jonls/redshift/issues/158#issuecomment-71329118

Comment 6 Jakub Jelen 2015-05-26 15:26:37 UTC
Just tested on Fedora 21 and clean install gives the same errors. What was fixed in geoclue?

Using:
geoclue2-2.1.10-2.fc21.x86_64
redshift-1.10-1.fc21.x86_64

Comment 7 Chad Versace 2015-05-27 14:03:57 UTC
If Geoclue's package maintainer decides to fix the bug by patching geoclue.conf, then I think redshift should be marked as a trusted system component. Unlike Chromium or a web app, the user can trust redshift to not hand over location information to advertisers ;).

Comment 8 Ryan Sawhill 2015-06-30 05:18:24 UTC
One more voice to agree that it would be great if our geoclue2 maintainer would add redshift as trusted by default. After all, if we can trust epiphany and firefox by default, I'd argue we can trust the comparitively simpler [code-base of] redshift.

Comment 9 Zeeshan Ali 2015-07-06 10:41:35 UTC
(In reply to Ryan Sawhill from comment #8)
> One more voice to agree that it would be great if our geoclue2 maintainer
> would add redshift as trusted by default.

There shouldn't be any need for that. You're likely hitting the issue of desktop file: You need to have a desktop file installed and also inform geoclue it's ID: http://www.freedesktop.org/software/geoclue/docs/gdbus-org.freedesktop.GeoClue2.Client.html#gdbus-property-org-freedesktop-GeoClue2-Client.DesktopId .

This is checked by agent (gnome-shell) and not geoclue btw. In future[1], these desktop ids will be important to identify apps.

[1] https://wiki.gnome.org/Projects/SandboxedApps

Comment 10 Zeeshan Ali 2015-07-06 14:13:11 UTC
(In reply to Chad Versace from comment #7)
> If Geoclue's package maintainer decides to fix the bug by patching
> geoclue.conf, then I think redshift should be marked as a trusted system
> component. Unlike Chromium or a web app, the user can trust redshift to not
> hand over location information to advertisers ;).

The idea is that at some point agents will get the ability to reliably identify apps and will ask user if they want to share their location. Currently agent only checks if desktop file is installed. This configuration in geoclue.conf is about apps that agent will not be asked about.

When agents start asking users, this will mean two notifications in case of web apps, that have their own mechanism for this in place as location is usually accessed by web pages rather than web browser itself. So  Apart from web browsers, we only add apps there that we know, only access location on user's explicit demand or need for user location is very central to it's core features (e.g gnome-maps).

Comment 11 Zeeshan Ali 2015-07-06 14:14:38 UTC
(In reply to Jakub Jelen from comment #6)
> Just tested on Fedora 21 and clean install gives the same errors. What was
> fixed in geoclue?

I backported some fixes from 2.2 release, mainly one that should allow geolocation to work on system/environment w/o any agent.

Comment 12 Zeeshan Ali 2015-07-06 14:17:27 UTC
I'll try to reproduce here to invetigate but in the meantime could you please check if redshift installs desktop file and geoclue's property is properly set before starting the client as pointed out in comment#9?

Comment 13 Zeeshan Ali 2015-07-06 14:38:40 UTC
Oh and could you please also ensure that you have geolocation enabled under privacy settings?

Comment 14 Zeeshan Ali 2015-07-06 14:40:13 UTC
(In reply to Zeeshan Ali from comment #13)
> Oh and could you please also ensure that you have geolocation enabled under
> privacy settings?

I'm asking cause I just tried against gnome-maps on F21 VM and at first it got the same error but then I enabled geolocation in settings and then it worked like a charm.

Comment 15 Lyude 2015-07-30 01:32:43 UTC
Hi! I noticed this got marked as NEEDINFO. I've been running into this with my Fedora system. So:
No, unfortunately enabling the Geolocation settings doesn't make a difference. The only fix I've found so far is adding the line mentioned here to the settings for geoclue.conf. This bug also still seems to be present on F22 unfortunately :(
In addition, I can confirm that redshift-gtk does in fact install the desktop file that's needed:

whitewolf%:~> rpm -ql redshift-gtk | grep desktop
/usr/share/applications/redshift-gtk.desktop

As for checking if the attribute is being set properly by redshift-gtk itself like you mentioned in comment #9, how would I go about checking this?

Comment 16 Zeeshan Ali 2015-07-30 12:42:40 UTC
(In reply to Stephen Chandler Paul from comment #15)
> Hi! I noticed this got marked as NEEDINFO. I've been running into this with
> my Fedora system. So:
> No, unfortunately enabling the Geolocation settings doesn't make a
> difference. The only fix I've found so far is adding the line mentioned here
> to the settings for geoclue.conf. This bug also still seems to be present on
> F22 unfortunately :(
> In addition, I can confirm that redshift-gtk does in fact install the
> desktop file that's needed:
> 
> whitewolf%:~> rpm -ql redshift-gtk | grep desktop
> /usr/share/applications/redshift-gtk.desktop

Interesting. I really don't know then. :( I see it's working fine for all the other apps in f22. If you have the latest geoclue (2.2.0) then my only guess is that DesktopId property is not set:

> As for checking if the attribute is being set properly by redshift-gtk
> itself like you mentioned in comment #9, how would I go about checking this?

By looking at the source code to see if it does that? It should be doing something like this: http://cgit.freedesktop.org/geoclue/tree/demo/where-am-i.c#n313

Comment 17 john.frankish 2015-08-01 15:27:19 UTC
I see the same issue with geoclue-2.2.0

$ sudo G_MESSAGES_DEBUG=Geoclue /usr/local/lib/geoclue-2.0/geoclue -t 60

(geoclue:18146): Geoclue-DEBUG: Available accuracy level from GClueWifi: 4
(geoclue:18146): Geoclue-DEBUG: WiFi device 'wlan0' added.
(geoclue:18146): Geoclue-DEBUG: Available accuracy level from GClueWifi: 6
(geoclue:18146): Geoclue-DEBUG: New agent for user ID '1001'
(geoclue:18146): Geoclue-DEBUG: Number of connected clients: 1
(geoclue:18146): Geoclue-DEBUG: 'org.gnome.Maps' not in configuration

..which is fixed by adding this to geoclue.conf

[org.gnome.Maps]
allowed=true
system=false
users=

Comment 18 Zeeshan Ali 2015-08-03 12:22:45 UTC
(In reply to john.frankish from comment #17)
> I see the same issue with geoclue-2.2.0
> 
> $ sudo G_MESSAGES_DEBUG=Geoclue /usr/local/lib/geoclue-2.0/geoclue -t 60
> 
> (geoclue:18146): Geoclue-DEBUG: Available accuracy level from GClueWifi: 4
> (geoclue:18146): Geoclue-DEBUG: WiFi device 'wlan0' added.
> (geoclue:18146): Geoclue-DEBUG: Available accuracy level from GClueWifi: 6
> (geoclue:18146): Geoclue-DEBUG: New agent for user ID '1001'
> (geoclue:18146): Geoclue-DEBUG: Number of connected clients: 1
> (geoclue:18146): Geoclue-DEBUG: 'org.gnome.Maps' not in configuration
> 
> ..which is fixed by adding this to geoclue.conf
> 
> [org.gnome.Maps]
> allowed=true
> system=false
> users=

Thanks John. Although it probably isn't relevant but just in case it is, John is on a non-Fedora (non-systemd) OS.

Comment 19 Zeeshan Ali 2015-08-03 16:01:15 UTC
(In reply to Stephen Chandler Paul from comment #15)
> Hi! I noticed this got marked as NEEDINFO. I've been running into this with
> my Fedora system. So:
> No, unfortunately enabling the Geolocation settings doesn't make a
> difference. The only fix I've found so far is adding the line mentioned here
> to the settings for geoclue.conf. This bug also still seems to be present on
> F22 unfortunately :(
> In addition, I can confirm that redshift-gtk does in fact install the
> desktop file that's needed:
> 
> whitewolf%:~> rpm -ql redshift-gtk | grep desktop
> /usr/share/applications/redshift-gtk.desktop
> 
> As for checking if the attribute is being set properly by redshift-gtk
> itself like you mentioned in comment #9, how would I go about checking this?

Ok, If I'm looking at the right sources, redshift is not setting the correct destkop ID:

http://bazaar.launchpad.net/~jonls/redshift/master/view/head:/src/location-geoclue2.c#L199

This should be 'redshift-gtk' rather than 'redshift' if desktop file is called 'redshift-gtk.desktop'. Could you please confirm this information?

Comment 20 Zeeshan Ali 2015-08-03 16:33:38 UTC
(In reply to Zeeshan Ali from comment #19)
> (In reply to Stephen Chandler Paul from comment #15)
> > Hi! I noticed this got marked as NEEDINFO. I've been running into this with
> > my Fedora system. So:
> > No, unfortunately enabling the Geolocation settings doesn't make a
> > difference. The only fix I've found so far is adding the line mentioned here
> > to the settings for geoclue.conf. This bug also still seems to be present on
> > F22 unfortunately :(
> > In addition, I can confirm that redshift-gtk does in fact install the
> > desktop file that's needed:
> > 
> > whitewolf%:~> rpm -ql redshift-gtk | grep desktop
> > /usr/share/applications/redshift-gtk.desktop
> > 
> > As for checking if the attribute is being set properly by redshift-gtk
> > itself like you mentioned in comment #9, how would I go about checking this?
> 
> Ok, If I'm looking at the right sources, redshift is not setting the correct
> destkop ID:
> 
> http://bazaar.launchpad.net/~jonls/redshift/master/view/head:/src/location-
> geoclue2.c#L199
> 
> This should be 'redshift-gtk' rather than 'redshift' if desktop file is
> called 'redshift-gtk.desktop'. Could you please confirm this information?

I actually see that at 'redshift.desktop' is also installed by Redshift, so if the version of Redshift in F22 contains this patch:

http://bazaar.launchpad.net/~jonls/redshift/master/revision/268.1.1

I'm once again stumped. I looked through code again and found a minor issue but nothing relevant to these two cases, reported here. :(

Comment 21 Vasco Rodrigues 2015-08-20 16:52:13 UTC
Still exists this bug.

Fixed by adding the lines, as suggested in the comments, to /etc/geoclue/geoclue.conf

[redshift]
allowed=true
system=false
users=

Comment 22 Maverick Kaung 2015-10-15 13:33:14 UTC
Just installed redshift-1.10.1.fc22, found that even after enabling "Location Services" in the "Privacy" settings, it still showed the same error. Looked through redshift's issue and came across this: https://github.com/jonls/redshift/issues/158#issuecomment-132177476

So created the `redshift.desktop` as suggested there. And the error is gone. Also tried with not having that desktop file and using `redshift-gtk` also shows the same error. So having that `redshift.desktop` also makes `redshift-gtk` work fine.

Comment 23 Zeeshan Ali 2015-10-16 21:02:59 UTC
(In reply to Ye Myat Kaung from comment #22)
> Just installed redshift-1.10.1.fc22, found that even after enabling
> "Location Services" in the "Privacy" settings, it still showed the same
> error. Looked through redshift's issue and came across this:
> https://github.com/jonls/redshift/issues/158#issuecomment-132177476
> 
> So created the `redshift.desktop` as suggested there. And the error is gone.
> Also tried with not having that desktop file and using `redshift-gtk` also
> shows the same error. So having that `redshift.desktop` also makes
> `redshift-gtk` work fine.

Thanks. So looking at the packaging, it seems the .spec file does not install the redshift.desktop file but only redshift-gtk.desktop. So either .spec file should also install the redshift.destkop file or sources need to specify redshift-gtk file to geoclue.

Comment 24 Dimitri Papadopoulos 2015-11-04 19:14:22 UTC
Similar findings on my Fedora 22 workstation:

Two executables are provided by the two redshift packages:
* redshift-1.10-1.fc22.x86_64 --> /usr/bin/redshift
* redshift-gtk-1.10-1.fc22.x86_64 --> /usr/bin/redshift-gtk

Only a single desktop file is provided by the 2nd package for the 2nd executable:
* redshift-gtk-1.10-1.fc22.x86_64 --> /usr/share/applications/redshift-gtk.desktop


On a vanilla Fedora 22 system both commands fail with this message:

$ redshift
Trying location provider `geoclue2'...
Using provider `geoclue2'.
Unable to start GeoClue client: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Access denied.
Unable to connect to GeoClue.
Unable to get location from provider.
$ 


Adding a redshift.desktop file immediatly fixes the problem for both executables:

$ sudo cp /usr/share/applications/redshift-gtk.desktop /usr/share/applications/redshift.desktop
$ 
$ redshift
Trying location provider `geoclue2'...
Using provider `geoclue2'.
Using method `randr'.
$ 

My guess is that redshift-gtk doesn't call geoclue2 itself. Instead it spawns redshift which does all the actual work. Since redshift lacks a desktop file, it does not have access to geoclue2. If I'm right, what's the proper way of fixing this issue? Adding a redshift.desktop file or changing redshift-gtk.desktop to redshift.desktop? Neither really make sense. It looks like desktop files are used by different subsystems for different reasons, providing an entry point for launching front-end software (redshift-gtk) or handling access of back-end software (redshift) to system resources. The requirements of each subsystem do not seem consistent.

Comment 25 Dimitri Papadopoulos 2015-11-05 13:42:02 UTC
See latest comment in upstream GitHub project:
  https://github.com/jonls/redshift/issues/158#issuecomment-154043492

The redshift.desktop file has already been added to redhsift:
  https://github.com/jonls/redshift/commit/3bb7a985

There has been no formal release that integrates this patch. Maybe Fedora should backport it to the current release.

Comment 26 Dimitri Papadopoulos 2015-11-14 13:17:06 UTC
Still there in Fedora 23.

Comment 27 Zeeshan Ali 2015-11-23 17:10:32 UTC
(In reply to Dimitri Papadopoulos from comment #24)
> Similar findings on my Fedora 22 workstation:
> 
> Two executables are provided by the two redshift packages:
> * redshift-1.10-1.fc22.x86_64 --> /usr/bin/redshift
> * redshift-gtk-1.10-1.fc22.x86_64 --> /usr/bin/redshift-gtk
> 
> Only a single desktop file is provided by the 2nd package for the 2nd
> executable:
> * redshift-gtk-1.10-1.fc22.x86_64 -->
> /usr/share/applications/redshift-gtk.desktop

That's the problem right there. Everything will work fine if redshift package also distributed it's .desktop file.

Comment 28 Zeeshan Ali 2015-11-23 17:18:48 UTC
(In reply to Dimitri Papadopoulos from comment #25)
> See latest comment in upstream GitHub project:
>   https://github.com/jonls/redshift/issues/158#issuecomment-154043492
> 
> The redshift.desktop file has already been added to redhsift:
>   https://github.com/jonls/redshift/commit/3bb7a985
> 
> There has been no formal release that integrates this patch. Maybe Fedora
> should backport it to the current release.

AFAICT, the package is not exactly using a release tarball but rather asking github to hand over a tarball containing sources of a particular commit. We just need to bump the commit I'd guess?

Comment 29 Dimitri Papadopoulos 2015-11-23 19:15:15 UTC
There are more formal releases from time to time, the last one being release 1.10 back in January 2015:
  https://github.com/jonls/redshift/releases

I agree even such releases are automatically created from a particular GitHub commit - a particular tag to be more precise. So yes, you could download the master.tar.gz tarball, as automatically created by GitHub from the latest commit in the master branch. Now I don't know how stable/buggy the current master branch is - as opposed to a formal release. My opinion on the subject doesn't really count, I'm only an end user.

Comment 30 Fedora Update System 2015-11-23 21:46:46 UTC
redshift-1.10-4.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-53169cd291

Comment 31 Fedora Update System 2015-11-23 21:46:47 UTC
redshift-1.10-4.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2015-329c6c59e4

Comment 32 Fedora Update System 2015-11-23 21:47:06 UTC
redshift-1.10-4.fc21 has been submitted as an update to Fedora 21. https://bodhi.fedoraproject.org/updates/FEDORA-2015-2b72345bc4

Comment 33 Fedora Update System 2015-11-25 02:54:55 UTC
redshift-1.10-4.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
$ su -c 'dnf --enablerepo=updates-testing update redshift'
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-53169cd291

Comment 34 Dimitri Papadopoulos 2015-11-25 17:12:56 UTC
Works for me after upgrading. Thanks!

Comment 35 Fedora Update System 2015-11-26 01:22:33 UTC
redshift-1.10-4.fc21 has been pushed to the Fedora 21 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
$ su -c 'dnf --enablerepo=updates-testing update redshift'
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-2b72345bc4

Comment 36 Fedora Update System 2015-11-26 02:27:12 UTC
redshift-1.10-4.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
$ su -c 'dnf --enablerepo=updates-testing update redshift'
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-329c6c59e4

Comment 37 Vasco Rodrigues 2015-11-26 03:04:21 UTC
Working after updating to the testing, no changes required to geoclue.

Comment 38 Fedora Update System 2015-11-30 21:20:30 UTC
redshift-1.10-4.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.

Comment 39 Fedora Update System 2015-12-04 21:21:02 UTC
redshift-1.10-4.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.

Comment 40 Dimitri Papadopoulos 2016-02-17 04:55:43 UTC
For what it's worth, redshift stopped working yesterday on my workstation, again:

$ redshift-gtk 
Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.
$ 

An error dialog appears that displays:

Failed to run Redshift
Trying location provider `geoclue2'...
Unable to start GeoClue client: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Geolocation disabled for UID 1000.
Unable to connect to GeoClue.
Unable to get location from provider.

Yet all *.desktop files are provided:

$ rpm -qf /usr/share/applications/redshift-gtk.desktop
redshift-gtk-1.11-1.fc23.x86_64
$ rpm -qf /usr/share/applications/redshift.desktop
redshift-1.11-1.fc23.x86_64
$ 

I'll open a new bug report because symptoms are similar but the reason seems slightly different.


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