Comment 7 for bug 1303962

Jussi and I discussed this quite a bit this morning. He explained that this is the process:
1. mediascanner2 scans files on the filesystem (eg, ~/Music and ~/Videos) and stores paths, file metadata (artist, album, etc) in ~/.cache/mediascanner2
2. apps use the QML plugin (which uses libmediascanner) to query the data in ~/.cache/mediascanner2
3. apps then can use the thumbnailer api to request the album via last.fm (this is cached on disk for later requests)

In '1', above, mediascanner2 runs unconfined and is a session service. It does not need any special consideration (though it should have an apparmor profile). In '2', the use of libmediascanner is in process to the app and therefore the app currently requires the reserved 'music_files_read/video_files_read' policy group otherwise an app can steal the mediascanner2 database for data mining, etc. For '3', there is no concern because the thumbnailer just fetches whatever it is told from last.fm (which the app could do itself).

What we need to protect is the scanned information in ~/.cache/mediascanner2 and access to ~/.cache/mediascanner2 should be considered privileged. DBus service should be created as a proxy to the data in ~/.cache/mediascanner2. This DBus service has direct access to ~/.cache/mediascanner2 and apps only have access to this DBus service (presumably via the QML plugin/libmediascanner). This service then becomes the trusted helper since it can perform the apparmor integration in this bug and the trust store integration in bug #1315381. Once this happens, this DBus api can be added to unprivileged policy groups (eg, audio/video).