1. 29 Oct, 2010 5 commits
  2. 28 Oct, 2010 4 commits
  3. 27 Oct, 2010 11 commits
  4. 26 Oct, 2010 9 commits
  5. 19 Oct, 2010 1 commit
  6. 18 Oct, 2010 1 commit
  7. 15 Oct, 2010 2 commits
    • Dan Williams's avatar
      core: ignore authorization for sleep/wake requests (but restrict to root) (rh #638640) · 8310593c
      Dan Williams authored
      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.
      8310593c
    • Jiří Klimeš's avatar
      libnm-glib: call D-Bus with a timeout when Set()ting properties · 9f2b48ef
      Jiří Klimeš authored
      The caller needs to be authenticated, so wait a bit to be sure
      it didn't quit too quickly.
      9f2b48ef
  8. 12 Oct, 2010 6 commits
    • Dan Williams's avatar
      settings: remove groups checking · fee318ab
      Dan Williams authored
      See "libnm-util: simplify permissions somewhat; remove groups"
      for more rationale.  Might come back later.
      fee318ab
    • Dan Williams's avatar
      libnm-util: simplify permissions somewhat; remove groups · 82772191
      Dan Williams authored
      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.
      82772191
    • Dan Williams's avatar
      supplicant: ratelimit supplicant activation · f532f41c
      Dan Williams authored
      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.
      f532f41c
    • Dan Williams's avatar
      supplicant: ignore unknown wpa_supplicant states · 39e111e5
      Dan Williams authored
      Don't treat them as DISCONNECTED.
      39e111e5
    • Dan Williams's avatar
      supplicant: prevent a race condition due to D-Bus activation · 48e37de3
      Dan Williams authored
      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.
      48e37de3
    • Dan Williams's avatar
      supplicant: make sure we remove the right interface · 5858c610
      Dan Williams authored
      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.
      5858c610
  9. 09 Oct, 2010 1 commit