Description of problem: On 32-bit systems, the pwconv and pwunconv utilities convert all uids greater than 2147483647 to just 2147483647. Version-Release number of selected component (if applicable): shadow-utils-4.0.17-18.el5.i386 How reproducible: every time Steps to Reproduce: 1. useradd -u 3000000000 -c "Big ID" bigid 2. id -u bigid ; id -g bigid 3. pwunconv 4. id -u bigid ; id -g bigid Actual results: uid and gid changed to 2147483647 Expected results: uid and gid are preserved at 3000000000 Additional info: See bug 505033 for useradd supporting uid > 2147483647
I re-compiled shadow-utils-4.1.4.2-9 from RHEL 6 on my RHEL 5.6 system and tested it and found that pwconv and pwunconv work correctly.
Created attachment 481463 [details] patch to fix pwconv and pwconv handling of large uids and gids The problem is the sgetpwent() and sgetgrent() functions from lib/sgetpwent.c and lib/sgetgrent.c use strtol() (or atoi() which calls strtol()) to convert the uid and gid to long ints which caps the uid to 2^31-1. Newer versions of shadow-utils have get_uid() and get_gid() functions in lib/* that use strtoll(). I tried adding lib/get_uid.c and lib/get_gid.c to RHEL 5 shadow-utils but this conflicts with other static copies of get_uid() and get_gid() found in src/{user,group}{add,mod}.c so I just copied the functions directly into lib/sgetpwent.c and lib/sgetgrent.c as static functions. See the attached patch.
Testing the patch from comment 2 shows it correctly preserves uid > 2147483647: [root@localhost ~]# rpm -q shadow-utils shadow-utils-4.0.17-18.el5.bz681020.i386 [root@localhost ~]# id -u bigid ; id -g bigid 3000000000 3000000000 [root@localhost ~]# pwunconv [root@localhost ~]# id -u bigid ; id -g bigid 3000000000 3000000000 [root@localhost ~]# pwconv [root@localhost ~]# id -u bigid ; id -g bigid 3000000000 3000000000
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2012-0244.html