Code review comment for lp://qastaging/~thomas-voss/location-service/fix-1219164

> The AppArmor policies are being looked up by pid which can be a racy
> interface. Do the races matter to us? Will something else in the system
> prevent the following chain of events?
>
> A process with pid 4242 running with AppArmor profile Foo makes a location
> request
> A process dies from some event
> B process with any pid spawns children until one has pid 4242
> C process with pid 4242 running with AppArmor profile Bar receives permission
> to use location from previous request
>
> It seems fairly unlikely, I'll admit, but if an attacker can chew up enough
> CPU time, some race conditions can become arbitrarily easy to exploit.
>

It's a very good point. To address it, I would propose:

  (1.) Query pid*, uid*, apparmor* profile from dbus daemon
  (2.) Query agent
  (3.) Query pid, uid, apparmor and compare to pid*, uid*, apparmor*

Issue and task is captured here: https://bugs.launchpad.net/location-service/+bug/1352978. However, I would think that we should land the MP as is to make sure we have fixed the critical RTM bug.
> Thanks