Do the check for system-owned secrets once, before kicking off the
request, instead of each time we ask an agent. As a bonus, this
change ensures priv->secrets doesn't store anything except
system-owned secrets too, simplifying some checks later on.
Not all connections will require every secret, and sometimes we
can't automatically figure out whether we need the secret. For
vpnc sometimes the group password isn't used, and sometimes PPP
providers require a username but don't want a password, etc.
Just because the key isn't saved (ie, the user hasn't entered it yet,
or the user want to type it in every time) doesn't mean the setting isn't
WEP, so recognize it as WEP if DEFAULTKEY or SECURITYMODE is set.
If we can authenticate the agent for 'modify' permission, then send
any existing system secrets to it as the user has permission to change
those secrets. This means the agent doesn't have to call GetSecrets()
itself, which means simpler code on the agent side for a slight LoC
hit in NM itself.
This also moves the permissions checking into the NMAgentManager to
check each agent, which is sub-optimal since now the agent manager
has to do PolicyKit stuff, but hey that's life. Agents need secrets,
and we do need to authenticate every agent before we send secrets to
them, and the NMSettingsConnection doesn't know about individual
agents at all.
If the agent returns system-owned secrets, like when activating a new
connection which was created with no secrets, make sure the agent is
authorized to modify network settings before saving or using the
new secrets.
Becuase there's only one 'flags' property for WEP keys (because it's pretty
dumb to have different flags for all 4 WEP keys) we need to do some tap dancing
with the secret name, so that requests for "wep-keyX" look up the "wep-key-flags"
property.
Duh, AND-ing flags with 0 (which is NM_SETTING_SECRET_FLAG_SYSTEM_OWNED)
is always going to be FALSE... NM_SETTING_SECRET_FLAG_SYSTEM_OWNED is
special; because it's the default value if the key isn't present,
and at this point it's exclusive of all other flags. So (at least for
now) it's OK that it's 0 but we might want to change it later so that
NM_SETTING_SECRET_FLAG_SYSTEM_OWNED can actually be used as a flag.
This allows the necessary flexibility when handling secrets; otherwise
it wouldn't be known when NM should save secrets returned from agents
to backing storage, or when the agents should store the secrets. We
can't simply use lack of a secret in persistent storage as the indicator
of this, as (for example) when creating a new connection without
secrets the storage method would be abmiguous.
At the same time, fold in "always ask" functionality for OTP tokens
so user agents don't have to store that attribute themselves out-of-band.
There was never a property for it anyway, so it never got serialized
across D-Bus, because it was folded into the "password" property in
wpa_supplicant between 0.5 and 0.6.
It's the thing that owns the secrets anyway, and it simplifies things to
have the secrets handling there instead of half in NMActRequest and
half in NMManager. It also means we can get rid of the ugly signals
that NMSettingsConnection had to emit to get agent's secrets, and
we can consolidate the requests for the persistent secrets that the
NMSettingsConnection owned into NMSettingsConnection itself instead
of also in NMAgentManager.
Since the NMActRequest and the NMVPNConnection classes already tracked
the underlying NMSettingsConnection representing the activation, its
trivial to just have them ask the NMSettingsConnection for secrets
instead of talking to the NMAgentManager. Thus, only the
NMSettingsConnection now has to know about the agent manager, and it
presents a cleaner interface to other objects further up the chain,
instead of having bits of the secrets request splattered around the
activation request, the VPN connection, the NMManager, etc.
The first-level hash table key should be the setting name itself,
not the GType name of the setting's GObject. There's probably a
better way to do this to reduce that confusion.
When a user makes an explicit request for secrets via GetSecrets
or activates a device, don't ask other users' agents for secrets.
Restrict secrets request to agents owned by the user that made the
initial activate or GetSecrets request.
Automatic activations still request secrets from any available agent.
A client calling GetSecrets on the connection should also request
secrets from agents in that client's session. ie, a connection
editor should be able to call GetSecrets, and get the secrets
stored by the agent in that session (the applet).
Simplifies code internally, and makes it easier for clients as well in
some cases where they want to control what ends up in the resulting
hash and what does not.
