GitLab

Braindead error handling on my part.

hash table already has the exported object path, no reason to ask
the connection itself for it.

Oops, got removed in an earlier commit.

NMSysconfigSettings has the authoritative list of connections, no reason
to duplicate all that tracking code in NMManager.  Add the missing bits
that the manager had to NMSysconfigSettings, and point NMPolicy at the
settings object instead of NMManager for that.

They almost do the same thing.

We'll need it for agent authentication too, so move it out of
system settings specific code.

Heavily modified from polkitbackendsessionmonitor.c, thanks davidz!

Everyone uses pm-utils still for sleep/wake support, and that's
traditionally how NM was put to sleep and woken up.  But pm-utils
uses dbus-send without --print-reply so dbus-send quits immediately
after sending the message.  That doesn't give NM enough time to
get the senders UID and thus validate the request, so the request
gets denied, and sometimes NM stays asleep after the machine is
woken up.

Instead, don't get the sender's UID and try to authorize it, but
just let the request go through.  Rely on D-Bus permissions to
make sure that only root can call sleep/wake methods.

The caller needs to be authenticated, so wait a bit to be sure
it didn't quit too quickly.

See "libnm-util: simplify permissions somewhat; remove groups"
for more rationale.  Might come back later.

Groups may come later, but they are also quite a bit more complicated
because getting the groups a user is in may require network access
if that user is backed by LDAP.  And it gets worse because you have
no idea that the glibc calls like getgrouplist(3) are backed by
the network and may take an arbitrary amount of time to complete.
Punt that.

If the supplicant dies a number of times within a short period of
time, make it go sit in the corner for a bit instead of continuously
trying to start it and have it die again.

Instead of just exposing a "running" value, instead make a meta
"available" value that's a combination of whether the supplicant
is actually running plus whether we want to talk to it right now
or not.

Don't treat them as DISCONNECTED.

interface_add() could get called from two places: by the wifi/eth
device class when activating (which if the supplicant isn't yet
running will D-Bus activate it) and from the NameOwnerChanged
handler for the wpa_supplicant dbus service smgr_running_cb().

So if the supplicant wasn't running, nm_supplicant_interface_new()
would call interface_add() to bring the supplicant to life via
activation, then go on and create priv->iface_proxy.  When the
supplicant appeared and D-Bus sent the NameOwnerChanged,
smgr_running_cb() would also call interface_add(), creating a
second priv->iface_proxy.  The first one got lost and lived after
its parent NMSupplicantInterface was killed, and could still
respond to signals over the bus.

Prevent that by adding another state, STARTING, that indicates
that we've already started talking to the supplicant.  Also be
extra paranoid about disconnecting signal handlers on the proxy.

It shouldn't ever happen that two interface objects for the same
network interface are active at the same time, but make sure we
yell if it does.

config.h defines _GNU_SOURCE, which in turn defines the bits necessary
for kill, isblank, and isascii.  So wherever we use those, we need
to make sure config.h is included.

Try to preserve custom hostnames (ie, anything not a localhost* variant,
the current hostname, or the previous hostname) when rewriting the
127.0.0.1/::1 localhost mapping lines.

Interpret the return value of kill(2) correctly...

Interpret the return value of kill(2) correctly...