Comment 13 for bug 1643732

For what it is worth, I think there is value in keeping the blank/no app ID mode working for the benefit of trusted helpers that need to work on behalf of a number of confined processes using different AppArmor labels. You could special case storage-framework, but I doubt we'll be the last to want this sort of access (heck, we're one of the first pieces of code using this new API).

Given that everything else in the API works with a blank app ID, I would tend to see the fact that this doesn't work as a bug rather than a result of undefined behaviour.

And looking at the D-Bus API, this still seems like a weird way to package up the information we need. At the moment, there are 3 ways to receive information about accounts:

 1. all accounts from the GetAccounts method.
 2. a changed account from the AccountChanged signal
 3. one account from RequestAccess method.

As it is now, the service information is only returned by GetAccounts, with no information being returned if an app ID hasn't been supplied. Given that AccountInfo already included an a{sv} dictionary, stashing the information there seems like a simpler solution. It would have ensured the information was available whichever way the client learned about the account, and it would piggyback on the filtering already performed on the account list.