Map data should be shared between apps

[Alberto Mardegan]

The libqtgeoservices_osm.so plugin gets loaded in the same process as the application using it, and stores all the map tiles into ~/.cache/<click-package>/

This means that different apps will be unable to share the data, leading to wasted filesystem space.

I suggest to modify the plugin so that:

1) Tiles are stored in a common place (and apparmor rules are relaxed to allow read access to that): ~/.cache/libqtgeoservices_osm/, for example

2) Tile downloads are managed by a separate service, started on demand.

[Alberto Mardegan (mardy)]

I had a chat with Alex Blasche from the Qt project about making the necessary changes to the QtLocation plugin API so that geoservice plugins would be allowed to use an external download manager and a tile cache service. He does not have objections to these extensions in principle, but it's up to us to make the first move.

I added the apparmor-easyprof-ubuntu project to the bug, because first of all we need to know if the security team agrees on opening up ~/.cache/QtLocation/ (this is the root dir where all cached tiles would be stored) for reading.

[Jamie Strandboge (jdstrand)]

My concern with allowing all apps access to ~/.cache/QtLocation is that it would be possible for an untrusted app to collect cached map data without the user's knowledge and send it off somewhere, which is why we don't share other caches (such as oxide's web cache). It would probably be ok to have an out of process trusted helper give access to/display these files in some way such that when an app contacted the trusted helper, it would display a trust prompt allowing access to shared location data.

[Alberto Mardegan (mardy)]

Hi Jamie, I think the privacy issue with the web cache is of a very different scale from the one you could get from collecting the map data. In the web cache you find visited websites, maybe with a lot of private information about the user. In the cache maps, on the other hand, the only information you can collect is a set of map tiles which might give some hint on where the user lives or has been travelling to, but even that with a lot of guesswork. I do see the issue, however.

There might be a solution, however: could we make give the apps the permission to only execute (traverse) the directories, and not read (enumerate) them?
In that way, it would not be possible for an app to get the list of the map tiles, while it would fulfil QtLocation caching needs (we know the file path of the tile we want to load, so we don't need read permissions on the directories).
Of course, an app could still try and read all the possible tiles one by one...

And if we go for the trusted prompt approach, what would be the action to be performed if the user grants the access? Would creating a hard link to ~/.cache/QtLocation from ~/.cache/<app>/QtLocation work?

[Seth Arnold (seth-arnold)]

Mardy, AppArmor always allows directory execute access.

/foo/directory/ r, is needed to enumerate files in the directory.

/foo/directory/* r, is needed to access the files in the directory, regardless if the names were guessed or read via getdents(2).

[Jamie Strandboge (jdstrand)]

This should be covered by the storage frameworks specification which will allow users to share data between apps in more meaningful ways via content-hub. As such, closing the apparmor-easyprof-ubuntu task.