Similar to "core: respect connection user permissions for activation/deactivation",
if a master connection is being activated because a slave connection requested
it, ensure that the user requesting the master connection is allowed to
activate it.
This appears to be a bug since the original 0.9.0 release when
connection permissions were implemented.
If all the following are true:
- the user is local (as determined by systemd or ConsoleKit)
- the user has been given the NETWORK_CONTROL PolicyKit permission
- the user is not listed in the connection's permissions
- the user knows the D-Bus object path of a connection which they
have no permissions for
then that user may activate/deactivate connections that are not
visible to that user as determined by the connection permissions.
Fix that by ensuring that these operations check whether the user
has permission.
These operations are *not* affected, and have always checked user
permissions before allowing the operation:
- modifying any connection details
- requesting any secrets or passwords for the connection
- deleting the connection
Use g_weak_ref_get() that either returns an object with reference increment or
returns NULL.
That fixes the problem. However, in the long run we should rework the editor
loop trying to merge that with GMainLoop, which could help for various issues.
https://bugzilla.redhat.com/show_bug.cgi?id=1011942
When receiving an IPv4/IPv6 address from the kernel, platform set the
timestamp to an invalid value before. The address timestamp must be set
to *now*, because the lifetime and preferred arguments are counting from
now.
Signed-off-by: Thomas Haller <thaller@redhat.com>
update_system_hostname() was bailing out if (there is no IP4 config or
the IP4 config has no addresses) AND (there is no IP6 config or the
IP6 config has no addresses), but it would then hit an assertion and
crash if there was a valid IP6 config along with an IP4 config with no
addresses. Fix that and get rid of some redundancy.
Sort of pointed out by Coverity.
When activating a never-before-used Wi-Fi network, we need to call
nm_client_add_and_activate_connection(), not
nm_client_activate_connection(). (We still pass a NULL connection,
since NM will attempt to auto-fill it for us, and will succeed as long
as it's not an 802.1x connection.)
We were using g_utf8_strlen() to measure strings for layout, but that
counts combining marks too, and also fails to deal with "fullwidth"
(ie, double-width) CJK characters.
Add a new utility function to do a better job of this (based on code
from vte), and use it everywhere.
"Cancel" didn't really make sense here, but changing it to "Quit" is
also weird because if you were going to use the "OK" button you'd have
to tab past "Quit" first... So make it be an option in the menu
instead.
Unless NMTUI_DEBUG is set, don't pop up a dialog when a
g_warning/critical/etc occurs. Just hide the main screen briefly so
the error doesn't get printed over the UI, and restore it after; any
messages that get logged will be visible after nmtui exits.
Since we can't align buttons to half-character positions, they end up
looking more random than centered:
| <Add> |
| <Edit...> |
| <Delete> |
So just let them be left-aligned instead. It looks better.
The keyboard focus was getting reset to the first widget any time a
widget changed validity, because the form wasn't updating priv->focus
when it should have.
Now UPDATED_BY_USER signal gets emitted immediately after the connection
is updated, rather then only after it is successfully saved.
This means, that the signal will be emitted earlier then before (right
after changing the connection, but before it gets commited).
Furthermore, the signal will also be emitted for connections that
get changed but are not to be saved.
Currently, the only subscriber to this signal is NMSettings
(default_wired_connection_updated_by_user_cb), which should be fine with
this change of semantics (even better).
https://bugzilla.redhat.com/show_bug.cgi?id=1040528
Signed-off-by: Thomas Haller <thaller@redhat.com>
This changes behaviour of nm_connection_update_secrets() in that it will
now return %TRUE, if there are no secrets to be cleared. Seems more
correct, to return success if there is nothing to do.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Often, nm_connection_clear_secrets does have no consequences, because
there is nothing to be cleared. Only raise a signal, if something
actually changed.
Signed-off-by: Thomas Haller <thaller@redhat.com>
