Bug#483645: [Pkg-shadow-devel] Bug#483645: Bug with UID=4294967296 on Alpha-Arch. (lenny/sid)
Hello, Nicolas, 31.05.08, 17:55, Nicolas François [EMAIL PROTECTED]: reassign 483645 glibc On Fri, May 30, 2008 at 06:43:07PM +0400, [EMAIL PROTECTED] wrote: 30.05.08, 13:28, Nicolas François [EMAIL PROTECTED]: On Fri, May 30, 2008 at 09:10:29AM +0200, [EMAIL PROTECTED] 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. I don't know all the details that you refer to, just wanted to add another 2c: I've checked sizeof(uid_t) on SPARC Solaris 9 (SunOS 5.9 Generic_122300-05 sun4u sparc SUNW,Sun-Fire) and HP-UX 11 (B.11.11 U 9000/800). On both of these (64bit) systems size of the uid_t is 4 (32 bit), same as on Tru64 UNIX. I think that uid_t size is 4 on almost every UNIX platform (this can be checked for at build time using autoconf). 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. I can't comment on glibc behaviour, but regarding the vipw/pwck/grpck, it could check that uid/gid are within the valid range. E.g. useradd/groupadd do check uid/gid against ranges (actually, whether it is a valid number or not at first): [EMAIL PROTECTED]:~# groupadd -g 4294967296 g32 groupadd: invalid numeric argument '4294967296' [EMAIL PROTECTED]:~# useradd -u 4294967296 u32 useradd: invalid numeric argument '4294967296' But if I add uid 4294967296 manually ( [EMAIL PROTECTED]:~# echo 'u32:x:4294967296:100::/root:/bin/bash' /etc/passwd [EMAIL PROTECTED]:~# echo 'u32::14000:0:9:7:::' /etc/shadow ), pwck does not complain. ;) After this, I can su to the 4294967296 user, but it looks like glibc cuts his uid to smth. like UID_MAX (this is for _i386_): [EMAIL PROTECTED]:~# su - u32 [EMAIL PROTECTED]:~$ id uid=4294967295(u32) gid=100(users) groups=100(users) I think that Debian/GNU on Alpha must exhibit the same behaviour. -- With best regards, xrgtn (+380501102966/ICQ:381730053/[EMAIL PROTECTED]) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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, [EMAIL PROTECTED] wrote: Hello, 30.05.08, 13:28, Nicolas François [EMAIL PROTECTED]: On Fri, May 30, 2008 at 09:10:29AM +0200, [EMAIL PROTECTED] 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#483645: Bug with UID=4294967296 on Alpha-Arch. (lenny/sid)
Package: login Version: 1:4.1.1-1 Architecture: alpha 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. $ grep test /etc/passwd test:x:4294967296:5000:,,,:/home/test:/bin/bash $ su - test Password: [EMAIL PROTECTED]:~# id uid=0(root) gid=5000(test) groups=5000(test) [EMAIL PROTECTED]:~# uname -a Linux testbox 2.6.21-2-alpha-generic #1 Thu Jul 12 03:14:26 UTC 2007 alpha GNU/Linux [EMAIL PROTECTED]:~# cat /etc/debian_version lenny/sid If I can provide further info or testing, no problem, just ask :-) Regards, Oliver -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#483645: [Pkg-shadow-devel] Bug#483645: Bug with UID=4294967296 on Alpha-Arch. (lenny/sid)
On Fri, May 30, 2008 at 09:10:29AM +0200, [EMAIL PROTECTED] 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.
$ grep test /etc/passwd
test:x:4294967296:5000:,,,:/home/test:/bin/bash
$ su - test
Password:
[EMAIL PROTECTED]:~# id
uid=0(root) gid=5000(test) groups=5000(test)
The bad news is that I can't reproduce this on i386. Thus I will have to
ask you questions.
If you create a file when logged in as user test (with su), does the file
belongs to root or to test?
In fact, I wonder if it is not a bug in id, which cast all the UIDs and
GIDs to (unsigned long int).
Also, are you able to compile some source on that box.
I would be interested by having the output of:
#include sys/types.h
#include pwd.h
#include stdio.h
void main (void)
{
struct passwd *pwd = getpwnam (test);
printf (test's UID: %llu\n, pwd-pw_uid);
}
It does not need to be run or compiled as user test, but the user test
should be present in /etc/passwd.
Last but not least, I do not recommend using these UIDs since it will
trigger bugs (in shadow or other softwares).
UID below 2^32 should be safe on all architectures.
(This is not a reason for not fixing these bugs, but it is a good reason
for administrators not to use these UIDs)
Best Regards,
--
Nekral
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#483645: [Pkg-shadow-devel] Bug#483645: Bug#483645: Bug with UID=4294967296 on Alpha-Arch. (lenny/sid)
Hello, 30.05.08, 13:28, Nicolas François [EMAIL PROTECTED]: On Fri, May 30, 2008 at 09:10:29AM +0200, [EMAIL PROTECTED] 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: HP Tru64 UNIX V5.1B (Rev. 2650); Fri Jul 27 14:32:42 EEST 2007 [EMAIL PROTECTED]:~$ grep uid_t /usr/include/sys/types.h typedef int uid_t; /* user ID */ typedef uint_t uid_t; /* user ID */ typedef unsigned int cpuid_t; [EMAIL PROTECTED]:~$ uname -a OSF1 xxx.yyy V5.1 2650 alpha [EMAIL PROTECTED]:~$ -- WBR, xrgtn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
