1. 12 Apr, 2012 1 commit
    • Alexander Larsson's avatar
      Fall back to SO_PEERCRED if credentials passing fails · 386f0f29
      Alexander Larsson authored
      Turns out libdbus doesn't send struct ucred credentials on linux, but
      just relies on the SO_PEERCRED support. However, gdbus does send, and
      expect to recieve a ucred credential. So, when libdbus talks to a
      gdbus server the authentication fails to send the credentials.
      
      We fix this by falling back to g_socket_get_credentials() if we don't
      get any credential messages.
      386f0f29
  2. 18 Jan, 2012 1 commit
  3. 27 May, 2011 1 commit
  4. 20 Apr, 2011 1 commit
  5. 08 Apr, 2011 1 commit
  6. 01 Feb, 2011 1 commit
  7. 29 Dec, 2010 1 commit
  8. 24 Sep, 2010 1 commit
  9. 09 Sep, 2010 1 commit
    • David Zeuthen's avatar
      GUnixConnection: Remove comment about Linux · a51df8ce
      David Zeuthen authored
      Since the previous commit, the g_unix_connection_send_credentials() /
      g_unix_connection_receive_credentials() functions now also works on
      FreeBSD since GUnixCredentialsMessage now works there.
      
      The main idea is that the g_unix_connection_send_credentials() /
      g_unix_connection_receive_credentials() functions are the "main" API
      for getting credentials (one way or the other). So it's better to
      avoid advertising where it is currently implemented.
      Signed-off-by: default avatarDavid Zeuthen <davidz@redhat.com>
      a51df8ce
  10. 20 Jul, 2010 1 commit
    • David Zeuthen's avatar
      Bug 617483 – Credentials passing · 7eba4134
      David Zeuthen authored
       - Make GCredentials instance and class structures private so it can't
         be subclassed and we don't have to worry about ABI compat
         issues. This also allows us to get rid of the GCredentialsPrivate
         struct.
      
       - Add a GCredentialsType enumeration that is used whenever exchanging
         pointers with the user. This allows us to support OSes with
         multiple native credential types. In particular, it allows
         supporting OSes where the native credential evolves or even changes
         over time.
      
       - Add g_socket_get_credentials() method.
      
       - Add tests for g_socket_get_credentials(). Right now this is in the
         GDBus peer-to-peer test case but we can change that later.
      
       - Move GTcpConnection into a separate gtk-doc page as was already
         half-done with GUnixConnection. Also finish the GUnixConnection
         move and ensure send_credentials() and receive_credentials()
         methods are in the docs. Also nuke comment about GTcpConnection
         being empty compared to its superclass.
      Signed-off-by: default avatarDavid Zeuthen <davidz@redhat.com>
      7eba4134
  11. 12 Jul, 2010 1 commit
  12. 07 Jul, 2010 1 commit
  13. 17 Jun, 2010 1 commit
  14. 14 May, 2010 1 commit
  15. 13 May, 2010 1 commit
  16. 09 May, 2010 1 commit
  17. 06 May, 2010 1 commit
  18. 30 Jun, 2009 1 commit
    • Dan Winship's avatar
      Add GCancellables to GSocket ops · 53beca95
      Dan Winship authored
      Currently, to implement cancellability correctly, all synchronous
      calls to GSocket must be preceded by a g_socket_condition_wait() call,
      (even though GSocket does this internally as well) and all
      asynchronous calls must do occasional manual
      g_cancellable_is_cancelled() checks. Since it's trivial to do these
      checks inside GSocket instead, and we don't particularly want to
      encourage people to use the APIs non-cancellably, move the
      cancellation support into GSocket and simplify the existing callers.
      
      http://bugzilla.gnome.org/show_bug.cgi?id=586797
      53beca95
  19. 27 May, 2009 1 commit
  20. 20 May, 2009 2 commits
    • Christian Persch's avatar
      Use g_set_error_literal · 80cfd099
      Christian Persch authored
      Bug #583206.
      80cfd099
    • Alexander Larsson's avatar
      Remove protocol names, instead use an enum with common protocols · 5cd86fbd
      Alexander Larsson authored
      The whole protocol name thing is pretty weird. The getprotobyname functions
      seem to only specify one mapping for name <-> ids, so all families/types
      must use the same values. Plus the values used for the protocols are
      standardized by IANA, so are always the same.
      
      So, we drop using names for protocols, intead introducing an enum with
      a few commonly availible and used protocols.
      5cd86fbd
  21. 18 May, 2009 1 commit
  22. 15 May, 2009 1 commit