Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

nixos/geoclue2: make configurable, can whitelist applications #45306

Closed

Conversation

worldofpeace
Copy link
Contributor

Motivation for this change

Non-functioning elementary geoclue2 agent

Eventually we'd like something similar to this but I'm unsure also, as mentioned, if elementary should be adding their agent into geoclue.conf upstream.

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Fits CONTRIBUTING.md.

cc @jtojnar

@@ -61,6 +88,106 @@ in
wantedBy = [ "default.target" ];
};
};

environment.etc."geoclue/geoclue.conf".text = ''
# Configuration file for Geoclue
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need most of these options or can we leave them implicit?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm seeing other projects just leaving it as is aside from using a custom geolocation api key from google.

Copy link
Contributor

@jtojnar jtojnar Aug 18, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One concern with the explicit defaults is that user cannot override them with extraConfig. If they cannot be omitted, we would need to make them configurable.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very true, maybe I'll make an option only to create more application configurations (since that's the only thing I'll need currently), and remove extraConfig. I'll deal with the rest later.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is mainly about the things already in the text. For example, someone might want to switch to google services or other provider. Or change their leaderboard name.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I also think this config file should be as minimal as possible, because it's not really possible to change anything in it, only add to it. The default upstream file is intended to be modified, which we can't like this

Alternatively, create a config option that transforms a Nix value into the config file syntax, and provide upstream defaults via config.gnome-color-panel.allowed = mkDefault true;. Then it's possible to override everything. I'm doing pretty much the same for #41467 (which I still need to finish)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The thing is that the config file's syntax and structure is not documented. So doing that fully is unclear.

@worldofpeace worldofpeace force-pushed the geoclue2-whitelisted-agents branch 4 times, most recently from 27899e3 to 0814aac Compare August 20, 2018 09:44

# Whitelist of desktop IDs (without .desktop part) of all agents we recognise,
# separated by a ';'.
whitelist=${optionalString cfg.enableDemoAgent semiColon "geoclue-demo-agent"}${semiColon "gnome-shell"}${semiColon cfg.extraWhitelistedAgents}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should not work for many reasons. I would try something like whitelist=${let whitelist = optional cfg.enableDemoAgent "geoclue-demo-agent" ++ singleton "gnome-shell" ++ cfg.extraWhitelistedAgents; in semiColon whitelist}

nixos/modules/services/desktops/geoclue2.nix Outdated Show resolved Hide resolved
nixos/modules/services/desktops/geoclue2.nix Outdated Show resolved Hide resolved
nixos/modules/services/desktops/geoclue2.nix Outdated Show resolved Hide resolved
@@ -61,6 +88,106 @@ in
wantedBy = [ "default.target" ];
};
};

environment.etc."geoclue/geoclue.conf".text = ''
# Configuration file for Geoclue
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I also think this config file should be as minimal as possible, because it's not really possible to change anything in it, only add to it. The default upstream file is intended to be modified, which we can't like this

Alternatively, create a config option that transforms a Nix value into the config file syntax, and provide upstream defaults via config.gnome-color-panel.allowed = mkDefault true;. Then it's possible to override everything. I'm doing pretty much the same for #41467 (which I still need to finish)

@michaelpj
Copy link
Contributor

So, as I understand it, the reason some gnome apps are hardcoded in is because geoclue doesn't have a "drop-in" mechanism for additional config files. So it's a real pain for installed applications to add themselves. This seems like a mistake, but not much we can do about it.

However, if we generate the file like this then we can allow modules to configure their own rules, even though upstream doesn't give us a drop-in mechanism. This seems like a win to me.

@michaelpj
Copy link
Contributor

This is still relevant - upstream have made some progress in making "system" apps not need the agent, so once they do a release we'll want to switch to whitelisting using an approach like this.

@worldofpeace
Copy link
Contributor Author

worldofpeace commented Oct 14, 2018

@michaelpj Cool, I'll finish cleaning this up in that case.

Edit: That was quick 🤣

@worldofpeace
Copy link
Contributor Author

So I'm ok with this, though it's rather unfortunate that I wrote this without awareness of lib.generators.toINI.
That would have made this much simpler.
If any maintainer feels like making that change feel free to push it.

@michaelpj

Note that in recent versions they've dropped the agent requirement for "system" apps, so we can potentially drop that whole annoyance and just go back to modifying the config file.

I think that means there's no usecase for enableDemoAgent or extraWhitelistedAgents, and the hacks for redshift can be dropped and replaced with

services.geoclue2.appConfig."redshift" = {
  isAllowed = true;
  isSystem = true;
};

I think...

@michaelpj
Copy link
Contributor

Yes, I agree. I'm happy to make that change once this is in, or you can do it.

All options within geoclue.conf[1] have been made configurable.

Additonally, we can now specify whether or not GeoClue
should ask the agent to authorize an application like so:
```
services.geoclue2.appConfig."redshift" = {
  isAllowed = true;
  isSystem = true;
};
```

[1]: https://gitlab.freedesktop.org/geoclue/geoclue/blob/master/data/geoclue.conf.in
@worldofpeace
Copy link
Contributor Author

I've dropped extraWhitelistedAgents because people should just upstream that config to geoclue IIRC.

I feel like the removal of enableDemoAgent should be in a different pr, coinciding with the redshift change once this is in.

@jtojnar Is this ok, or do you still have reservations about it?

@worldofpeace worldofpeace changed the title nixos/geoclue2: add ability to whitelist agents and append to config nixos/geoclue2: make configurable, can whitelist applications Dec 2, 2018
@michaelpj
Copy link
Contributor

michaelpj commented Dec 4, 2018

I had a brief look at what they actually did to implement "system apps don't need authorization" and I'm not sure that it corresponds to the system config option at all. I'll investigate separately.

@michaelpj
Copy link
Contributor

Things I would like to see from this:

  • Use toINI
  • Move whichever bits of configuration we can to the right modules. Just because upstream doesn't have a drop-in mechanism and so has to hardcode things doesn't mean that we have to.

@worldofpeace
Copy link
Contributor Author

Move whichever bits of configuration we can to the right modules.

I can do that for gnome, however I can't for epiphany, and for firefox I'm not sure.

@michaelpj
Copy link
Contributor

Sure, for things that don't have a module there's nothing we can do at the moment.

@michaelpj
Copy link
Contributor

Also I guess the whitelisting of the elementary agent could come from that module?

@leotaku
Copy link
Contributor

leotaku commented Apr 30, 2019

Is there anything we can do to push this forward?

@michaelpj are you still interested in rewriting/seeing this rewritten to use toINI?

@michaelpj
Copy link
Contributor

I still think this would be useful indeed! I kind of gave up on geoclue, but it would be nice if it worked better.

@worldofpeace
Copy link
Contributor Author

Completed in #60681

@worldofpeace worldofpeace deleted the geoclue2-whitelisted-agents branch May 16, 2019 22:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants