Theo de Raadt <dera...@cvs.openbsd.org> writes:
>>This should make things better on 32 bits archs in a few years.
>>Tested on amd64 by changing the format to "%d".
>>
>>ok?
>>
>>Index: edit.c
>>===================================================================
>>RCS file: /cvs/src/usr.bin/chpass/edit.c,v
>>retrieving revision 1.34
>>diff -u -p -p -u -r1.34 edit.c
>>--- edit.c 26 Nov 2013 13:18:55 -0000 1.34
>>+++ edit.c 4 Jan 2015 22:29:31 -0000
>>@@ -214,10 +214,10 @@ bad:
>>(void)fclose(fp);
>> pw->pw_gecos = p;
>>
>> if (snprintf(buf, sizeof(buf),
>>- "%s:%s:%u:%u:%s:%ld:%ld:%s:%s:%s",
>>+ "%s:%s:%u:%u:%s:%lld:%lld:%s:%s:%s",
>> pw->pw_name, pw->pw_passwd, pw->pw_uid, pw->pw_gid, pw->pw_class,
>>- (long)pw->pw_change, (long)pw->pw_expire, pw->pw_gecos, pw->pw_dir,
>>- pw->pw_shell) >= 1023 ||
>>+ (long long)pw->pw_change, (long long)pw->pw_expire, pw->pw_gecos,
>>+ pw->pw_dir, pw->pw_shell) >= 1023 ||
>> strlen(buf) + alen >= 1023) {
>> warnx("entries too long");
>> free(p);
>
> Unfortunately getpwent() is still using strtol(), so what you propose
> is dangerous and wrong, since getpwent() will now ignore those entries
> which it parses as invalid (number too long, or too many digits, it is
> unclear to me how strtol will handle this situation).
Ah, ok.
> No short hacks, please. I do not think this change on it's own makes
> anything better. This needs a comprehensive change with tests.
Ack.
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
