Problem with signed vs unsigned treatment of uid

[Thomas Hood]

I've been researching the appearance of an error message in sssd_nss.log.

     [sssd[nss]] [nss_cmd_getpwuid_search] (0x0040): No matching domain found for [-1], fail!

Although I don't know yet where this "-1" is coming from, I have discovered something else which indicates a (possibly unrelated) bug.

Cranking up the debug_level we see the following when doing "su -c pwd foo"

(Sun Oct 14 17:47:33 2012) [sssd[nss]] [nss_cmd_getpwuid_search] (0x0100): Requesting info for [-1@SAMBA]
(Sun Oct 14 17:47:33 2012) [sssd[nss]] [sss_dp_issue_request] (0x0400): Issuing request for [0x42bcd0:1:-1@SAMBA]
(Sun Oct 14 17:47:33 2012) [sssd[nss]] [sss_dp_get_account_msg] (0x0400): Creating request for [SAMBA][4097][1][idnumber=4294967295]
(Sun Oct 14 17:47:33 2012) [sssd[nss]] [sss_dp_internal_get_send] (0x0400): Entering request [0x42bcd0:1:-1@SAMBA]
(Sun Oct 14 17:47:33 2012) [sssd[nss]] [nss_cmd_getpwuid_search] (0x0100): Requesting info for [-1@SAMBA]
(Sun Oct 14 17:47:33 2012) [sssd[nss]] [nss_cmd_getpwuid_search] (0x0040): No matching domain found for [-1], fail!
(Sun Oct 14 17:47:33 2012) [sssd[nss]] [sss_dp_req_destructor] (0x0400): Deleting request: [0x42bcd0:1:-1@SAMBA]
(Sun Oct 14 17:47:33 2012) [sssd[nss]] [sss_parse_name_for_domains] (0x0200): name 'foo' matched without domain, user is foo
[...]

Adding

   max_id = 999999

to the [domain/SAMBA] section of sssd.conf changes this to:

(Sun Oct 14 17:49:32 2012) [sssd[nss]] [nss_cmd_getpwuid_search] (0x0100): Uid [4294967295] does not exist in domain [SAMBA]! (id out of range)
(Sun Oct 14 17:49:32 2012) [sssd[nss]] [nss_cmd_getpwuid_search] (0x0040): No matching domain found for [-1], fail!
(Sun Oct 14 17:49:32 2012) [sssd[nss]] [sss_parse_name_for_domains] (0x0200): name 'foo' matched without domain, user is foo

It seems that although the uid is printed out as a signed integer, it is compared with the max_id value as an unsigned integer.

[Stephen Gallagher (stephen-gallagherhome)]

-1 commonly appears as part of an ancient NFS bug that returns -1 as the value of the UID if the user is being cast into 'nobody'. We've seen a similar bug elsewhere in the code before.

That log message *is* related. It looks like in certain places we're casting the value to signed before printing it, but internally we're maintaining it as -1.

Probably we could be handling this better, but it's unlikely to matter much in the real world. Users with that ID are being given it because the NFS server doesn't want them to have any real permissions.