The state of the Location permission on Fedora Linux in 2025

This article will discuss the state of finding your current geographical location in the Fedora Linux environment.

Background

For many mobile devices it is useful to get the current location. This is usually done using a GPS sensor, where the coordinates (latitude and longitude as given by the satellites) allow for step-by-step directions to the desired destination.

However, sometimes using the GPS isn’t desirable. This may be due to the high battery usage, or sometimes the device doesn’t have a GPS sensor at all. Even more interesting, the user might hit a GPS sensor limitation (such as being indoors) meaning there is a need for a secondary way to detect location to either replace or augment the GPS data.

But, what would that secondary source of data be? The alternative source needs to be some public data that is available for everyone, and we do have those! There are Wifi network identifiers, mobile cell towers data, and Bluetooth beacons. All of these are broadcast constantly, or almost constantly.

Using these alternative sources the user accepts the service of a location service provider (for example, Google Location Services provided by Google on Android). The provider has their own database of the specified device identifiers along with their approximate location. When making a location request the Wifi, Bluetooth, and cell identifiers are sent with the request and the location provider sends back coordinates. In addition they provide the precision of the coordinates based on an average of the locations available from the data in the database.

Of course, there is always the third option of combining both approaches in a way that fits the precision needed for the task. As an example, Google calls this combined approach Fused Location which is provided in their proprietary Google Play Services.

Ok, that is how it generally works and how mobile devices do it. But what about Linux?

So, how does it work on Linux?

In Linux, the software responsible for handling the location requests is Geoclue. As the Geoclue project puts it:

Geoclue is a D-Bus service that provides location information. The goal of the Geoclue project is to make creating location-aware applications as simple as possible.

Geoclue is capable of, among other things:

• Support for location data based on Wifi (via wpa_supplicant integration. This uses Mozilla Location Service (MLS) by default)
• Support for location data using GPS (if available)
• Support for location data using mobile modems (via ModemManager integration)
• GeoIP support (fallback mode)

Previously the Mozilla Location Service (MLS) was the default location service used under Linux. Unfortunately, in March 2024, Mozilla announced the project was being discontinued, making it necessary to switch to an alternative.

Mozilla Location Services and Ichnaea

Mozilla’s no longer available service called “Mozilla Location Services” (MLS) utilized the open source Ichnaea software. The service was capable of both receiving submitted user-data as well as responding with the approximate location based on user requests.

For submitting new data, users could use use a “stumbler” application. This was able to collect cell data, Wifi data and Bluetooth beacons, associate them with their location, and submit them to MLS or another Ichnea-compatible service.

Users would utilize the collected data by having their system (in the case of Linux or some Android ROMs using MLS) send the info about the radio devices in range and receive back info about the approximate location.

MLS alternatives and setup

Although there are many possible MLS alternatives (As long as they maintain Ichnaea compatibiltiy), the main alternative those days is beaconDB.

To set up beaconDB set the URL to

.

Or as adapted from their website:

$ sudo mkdir /etc/geoclue/conf.d
$ sudo nano /etc/geoclue/conf.d/99-beacondb.conf
[wifi]
enable=true
url=https://api.beacondb.net/v1/geolocate
$ sudo systemctl reload geoclue

After restarting Geoclue you should have access to beaconDB.

A future article will focus on submitting new data, this might require an Android phone.

Notes

• If there’s not enough data for your region yet, you might not have a very good experience. Consider looking at the beaconDB map before making the switch or submitting data for your region.

• The Geoclue integration with Wifi networks requires wpa_supplicant, since currently only a wpa_supplicant backend exists. This means iwd users won’t be able to use Geoclue correctly since there is no Geoclue iwd support and no Wifi data will be sent. Instead fall back to beaconDB’s GeoIP implementation will occur.

• There is a chance beaconDB’s implementation of GeoIP might be potentially worse than Geoclue’s own implementation. This could be explained by geoclue currently relying on Google, although in the future it will switch to using reallyfreegeoip. This will be noticed if city-level locations are not precise, such as showing the location a few cities away from the user actual location.