This was reported to me by a clueful user who told me that restarting NetworkManager didn't help. And I'm fairly sure that when I restarted NetworkManager during my *initial* testing tonight, he was right.

But *now*, I can remove the n-m-openconnect package, reboot, then reinstall it and all I have to do is restart NetworkManager to make things work.

Dan?

What appears to be happening here is that newly written rules (from the VPN plugin) are not loaded into NM's bus policy.  The attached logs are the result of rebuilding dbus-daemon with verbose mode and adding a bunch of logging to teh rules processing.  You'll note in the "good" log that there's a rule:

1201: [policy.c(895):dump_rule] (0x12091a8) SEND ALLOW T:invalid path:'(none)' intf:'(none)' memb:'(none)' err:'(none)' dest:'org.freedesktop.NetworkManager.vpnc' eavs:0 rrep:1 log:0
1201: [policy.c(1116):bus_client_policy_check_can_send]   (policy) used rule, allow now = 1

but this rule is not present in the "bad" log.  The only difference between the good and bad logs is that after the bad log, and before the good log, the NetworkManager service was restarted.  Thus the theory that the new rules were only loaded into NM's bus policy when NM was restarted, not when the new rules were written to disk.

Created attachment 50386 [details]
Log of policy denial

Created attachment 50387 [details]
Log of policy allow (good)

dbus-daemon is meant to re-read policy files when they change (it uses Linux inotify, Linux dnotify or FreeBSD kqueue where supported), but perhaps it only re-reads pre-existing files, and doesn't re-scan the directory itself?

Our hypothesis was the the files *are* reloaded, but the changed rules only apply to *new* clients. The existing clients which were running before the change, are still operating under the old rules. Hence having to restart NM before the new rules apply to it.

Crap - looks to me you guys are right, the bus does cache the policy per client =(

It looks like this is done partly to optimize the rules per-client.

We may be able to call bus_policy_create_client_policy() after reloading for each connection.  (With suitable changes to unref the existing policy).

Created attachment 90561 [details] [review]
[PATCH] Reload policy rules for completed connections

The message bus which can monitor its conf dirs for changes and reload
confs immediately if dir monitor enabled, for example, inotify in Linux,
kqueue in *BSD.

However, it doesn't apply policy rules change for completed connections,
so to apply policy rules change, the client connection has to disconnect
first and then re-connect to message bus.

For imcomplete connections, it always has the latest review of policy
rules.

Created attachment 90562 [details] [review]
[debug patch] bus_client_policy_print() added to print policy rules of connection

This patch is on my debug-dev branch, I'm not sure you'd like to apply it to master branch, it's only useful for debugging.

Comment on attachment 90561 [details] [review]
[PATCH] Reload policy rules for completed connections

Review of attachment 90561 [details] [review]:
-----------------------------------------------------------------

Makes sense.

(In reply to comment #9)
> This patch is on my debug-dev branch, I'm not sure you'd like to apply it to
> master branch, it's only useful for debugging.

I'm not going to add unused functions, no.

I wouldn't mind adding it if it was called from an appropriate place (just after setting d->policy, perhaps), used _dbus_verbose instead of _dbus_warn, and was empty (a no-op) unless defined(DBUS_ENABLE_VERBOSE) (or whatever that mode is really called, if that's not it).

Fixed in git for 1.7.10, thanks