Use case:
A user has an auto-activatable connection with secrets in a keyring. While
booting NM starts and tries to activate the connection, but it fails because of
missing secrets. Then the user logs in, but the connection is marked as invalid
and is not tried again.
This commit solves the issue by removing invalid flag and activating the
connection when a secret agent registers.
Signed-off-by: Jiří Klimeš <jklimes@redhat.com>
The core problem was the nm_connection_need_secrets() call in
nm-agent-manager.c's get_start() function; for VPN settings this
always returns TRUE. Thus if a VPN connection had only system
secrets, when the agent manager checked if additional secrets
were required, they would be, and agents would be asked for
secrets they didn't have and couldn't provide. Thus the
connection would fail. nm_connection_need_secrets() simply
can't know if VPN secrets are really required because it
doesn't know anything about the internal VPN private data;
only the plugin itself can tell us if secrets are required.
If the system secrets are sufficient we shouldn't be asking any
agents for secrets at all. So implement a three-step secrets
path for VPN connections. First we retrieve existing system
secrets, and ask the plugin if these are sufficient. Second we
request both existing system secrets and existing agent secrets
and again ask the plugin if these are sufficient. If both those
fail, we ask agents for new secrets.
All non-VPN secrets are considered system-owned if they do not
have any explicitly set secret flags, and this makes VPN secrets
treated the same way. As part of the import process plugins and
the applet already update secret flags. This ensures that VPN
secrets are treated consistently throughout the codebase.
Use one global PolkitAuthority object; we only really need to use it
in one place anyway. So consolidate the code that uses polkit into
nm-manager-auth.c.
If the connection had system secrets, previously the settings core
would consider those sufficient even if the device code had requested
new secrets because the old ones didn't work.
Can't just check whether we have existing system secrets, because
that doesn't catch the case for a completely new connection where
there may not be any secrets yet, but any that we do get should
be system-owned.
When a connection is visible only to one user, check 'own' instead
of 'system', allowing 'own' to be less restrictive since the change
won't affect any other users.
Meaning stays the same, but this will allow us to differentiate
in the future between personal connections (ie, just visible to
one user) and system connections (visible to more than one user).
We need to iterate through each item in the VPN's 'secrets' property
and mark it as not required, instead of just marking the 'secrets'
property itself as not required. Yeah, VPN secrets are a bit
annoying.
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.
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.
