Re: Bug#483645: Bug with UID=4294967296 on Alpha-Arch. (lenny/sid)
reassign 483645 glibc
thanks
On Fri, May 30, 2008 at 06:43:07PM +0400, xrgtn@yandex.ru wrote:
> Hello,
>
> 30.05.08, 13:28, "Nicolas François" <nicolas.francois@centraliens.net>:
> > On Fri, May 30, 2008 at 09:10:29AM +0200, oliver.morais@akhwien.at wrote:
> > > Creating an user-account and changing the UID via vipw to "4294967296"
> > > (Which is 2^32) results in an overflow and the user gets the UID=0,
> > > an UID of "4294967297" leads to an UID=1 and so on.
>
> Maybe this is a platform limit (passwd.pw_uid is of uid_t type).
> For example, on 64-bit HP Tru64 I see the next:
It looks like a glibc bug to me.
At least, INT_FIELD should check for ERANGE after calling strtoul
(in nss/nss_files/files-parse.c)
On i386, all UIDs >= 4294967296 are silently converted to 4294967295.
(when IMHO, an error should be returned by getpwnam)
Also, the glibc should check if the UID returned by strtoul fits in the
range of allowed UIDs.
What might happen on Alpha is that "4294967296" is successfully converted
to the unsigned long 4294967296, but it is then converted to a unsigned
int, and thus becomes zero.
(I've no Alpha, and could not check this; but on i386, uid_t is an
__UID_T_TYPE, defined to __U32_TYPE in /usr/include/bits/typesizes.h (and
this seems to be the same on alpha)
I did not check which parts of the glibc call INT_FIELD, and thus I don't
know if the fix can simply be applied to INT_FIELD.
Best Regards,
--
Nekral
Reply to: