The way it works is that added constraints now look like this

scope=always:action-id=org.pulseaudio.acquire-high-priority:when=1197004781:auth-as=0:constraint=local:constraint=active:constraint=exe%3A%2Fusr%2Fbin%2Fpulseaudio:constraint=selinux_context%3Asystem_u%3Asystem_r%3Aunconfined_t

or if not using SELinux like this

scope=always:action-id=org.freedesktop.hal.storage.mount-fixed:when=1197008218:auth-as=0:constraint=local:constraint=active:constraint=exe%3A%2Fusr%2Fbin%2Fgnome-mount

This is a bit icky to implement for mechanisms, like HAL, running as
an unprivileged user. The problem is that we can't resolve the symlink
/proc/pid/exe. On the other hands such mechanisms has the
authorization org.freedesktop.policykit.read already. So use that.

Note that this is what some people call snake-oil. The reason is in the
docs for polkit_sysdeps_get_pid_for_exe(); copying it here so I can point
people to this commit in the future

  Get the name of the binary a given process was started from.

  Note that this is not necessary reliable information and as such
  shouldn't be relied on 100% to make a security decision. In fact,
  this information is only trustworthy in situations where the given
  binary is securely locked down meaning that 1) it can't be
  ptrace(2)'d; 2) libc secure mode kicks in (e.g LD_PRELOAD won't
  work); 3) there are no other attack vectors (e.g. GTK_MODULES, X11,
  CORBA, D-Bus) to patch running code into the process.

  In other words: the risk of relying on constraining an authorization
  to the output of this function is high. Suppose that the program
  /usr/bin/gullible obtains an authorization via authentication for
  the action org.example.foo. We add a constraint to say that the
  gained authorization only applies to processes for whom
  /proc/pid/exe points to /usr/bin/gullible. Now enter
  /usr/bin/evil. It knows that the program /usr/bin/gullible is not
  "securely locked down" (per the definition in the above
  paragraph). So /usr/bin/evil simply sets LD_PRELOAD and execs
  /usr/bin/gullible and it can now run code in a process where
  /proc/pid/exe points to /usr/bin/gullible. Thus, the recently gained
  authorization for org.example.foo applies. Also, /usr/bin/evil could
  use a host of other attack vectors to run it's own code under the
  disguise of pretending to be /usr/bin/gullible.

  Specifically for interpreted languages like Python and Mono it is
  the case that /proc/pid/exe always points to /usr/bin/python
  resp. /usr/bin/mono. Thus, it's not very useful to rely on that the
  result for this function if you want to constrain an authorization
  to e.g. /usr/bin/tomboy or /usr/bin/banshee.

However. Once we have a framework for running secure desktop apps this
will start to make sense. Such a framework includes securing X (using
e.g. XACE with SELinux) and making the UI toolkit secure as well. It's
a lot of work.

Until then these constraints at least makes it harder to for malicious
apps to abuse PolicyKit authorizations gained by other users.