dbus-sysdeps-unix: don't add (uid_t)-1 to creds

If I set a breakpoint on the call to _dbus_credentials_add_unix_uid
further down in this function and run the loopback test, I can see
that sometimes it's getting called with a uid of 4294967295.  This is
not intended, but happens because the -1 value returned from
SO_PEERCRED is interpreted as a uid of 4294967295, because if uid_t is
unsigned, it won't be sign extended when assigned to uid_read.

As far as I can tell, every other API used in this function to get
uid/gid on some system returns an error when there's no credential
information (e.g. on a non-unix socket), rather than returning -1, so
they shouldn't have to do this check.

Fixes: 01af5ff4 ("add credentials support, add EXTERNAL auth mechanism")
Signed-off-by: Alyssa Ross <hi@alyssa.is>

diff --git a/dbus/dbus-sysdeps-unix.c b/dbus/dbus-sysdeps-unix.c
index eec9b20cf853dba4393bc145c542399af8db2271..aae9c4045995ab2cb8c3542896ea1a21e4f969d4 100644 (file)
--- a/dbus/dbus-sysdeps-unix.c
+++ b/dbus/dbus-sysdeps-unix.c
@@ -2321,13 +2321,17 @@ _dbus_read_credentials_socket  (DBusSocket       client_fd,
       }
     else
       {
-        pid_read = cr.pid;
-        uid_read = cr.uid;
+        if (cr.pid != 0)
+          pid_read = cr.pid;
+
+        if (cr.uid != (uid_t)-1)
+          uid_read = cr.uid;
 #ifdef __linux__
         /* Do other platforms have cr.gid? (Not that it really matters,
          * because the gid is useless to us unless we know the complete
          * group vector, which we only know on Linux.) */
-        primary_gid_read = cr.gid;
+        if (cr.gid != (gid_t)-1)
+          primary_gid_read = cr.gid;
 #endif
       }