Re: [PATCH] Do not truncate large UID/GID values on 32bit architectures

[Jakub Hrozek <jhrozek [at] redhat.com>]

On Sat, Aug 27, 2011 at 11:24:06PM +0200, Arthur de Jong wrote:
> On Sat, 2011-08-27 at 23:13 +0200, Arthur de Jong wrote:
> > I think the first issue could be addressed by picking strtoul() or
> > strtoull() depending on the size of long int, long long int and uid_t.
> 
> In fact this was easier than I thought:
>   http://arthurdejong.org/viewvc/nss-pam-ldapd?view=rev&revision=1524
> 
> Thanks again for the patch!
> 

I'm sorry, but this doesn't work for me:

In file included from myldap.c:75:0:
    common.h:142:2: error: #error unable to find implementation for
    strtouid()
    common.h:151:2: error: #error unable to find implementation for
    strtogid()

On my system (a 64bit Linux machine), SIZEOF_UID_T is 4 but both
SIZEOF_UNSIGNED_LONG_INT and SIZEOF_UNSIGNED_LONG_LONG_INT are 8.
So none of the #if-s match.

The reason I originally used uint32 was that on my system, it is defined
as:
    #define __U32_TYPE              unsigned int
    #define __UID_T_TYPE            __U32_TYPE

I would suggest that the equality check is changed to "<=" and perhaps 
"unsigned int" is added to the list of data types.

One more thing that needs to be addressed is checking for overflows.
According to the POSIX standard:
    The types uid_t and gid_t are magic cookies. There is no {UID_MAX}
    defined by POSIX.1

So I think the best option is to either check for overflow based on the
sizeof(uid_t) value or alternatively just check if the unsigned long
overflowed, for example. The latter is less work, but prone to overflows
in case ULONG_MAX would be bigger than (hypothetical) UID_MAX.

I'm willing to do the coding if we agree on a solution.
-- 
To unsubscribe send an email to
nss-pam-ldapd-users-unsubscribe@lists.arthurdejong.org or see
http://lists.arthurdejong.org/nss-pam-ldapd-users