svn commit: r285985 - in head/usr.sbin/pw: . tests

[Bruce Evans]

On Sat, 1 Aug 2015, Jilles Tjoelker wrote:

> On Wed, Jul 29, 2015 at 08:52:52AM +1000, Bruce Evans wrote:
>> On Tue, 28 Jul 2015, Baptiste Daroussin wrote:
>>> Added: head/usr.sbin/pw/tests/pw_groupadd.sh
>>> ==============================================================================
>>> --- /dev/null	00:00:00 1970	(empty, because file is newly added)
>>> +++ head/usr.sbin/pw/tests/pw_groupadd.sh	Tue Jul 28 21:10:58 2015	(r285985)
>>> @@ -0,0 +1,15 @@
>>> +# $FreeBSD$
>>> +
>>> +# Import helper functions
>>> +. $(atf_get_srcdir)/helper_functions.shin
>>> +
>>> +atf_test_case group_add_gid_too_large
>>> +group_add_gid_too_large_body() {
>>> +	populate_etc_skel
>>> +	atf_check -s exit:64 -e inline:"pw: Bad id '9999999999999': too large\n" \
>>> +		${PW} groupadd -n test1 -g 9999999999999
>>> +}
>
>> Check for large valid ids on i386 (should succeed, but currently fail),
>> negative ids (require failure), magic ids like (uid_t)-1 and (uid_t)-2
>> (should fail, but currently succeed on amd64), and the hex ids (should
>> succeed, but currently fail).  (uid_t)-1 is special for some syscalls,
>> so shouldn't be permitted for users.  (uid_t)-2 special for nfs (see
>> exports(5)).  The magic ids are hard to spell without using hex, but
>> pw is too broken to accept that.  For 32-bit ids, the above number
>> should be replaced by 0x100000000 when pw supports hex.  Also check
>> that 0xffffffff and 0xfffffffe are not too large, but reserved, and
>> that 0xfffffffd is not too large and not reserved.
>
> These values are easily written using arithmetic expansion, for example
> largeid=$((0x100000000)).

Not really.  Shells are also very buggy or limited in this area.  I
often use old versions of sh and bash that only support up to INT32_MAX
and have broken overflow handling.  /bin/sh in -current only supports
up to INT64_MAX (or maybe INTMAX_MAX) and has broken overflow handling
(it clamps to INT64_MAX).  Not so old versions of bash only support
up to INT64_MAX and have differently broken overflow handling (4.3.99
blindly assigns to int64_t, so $((0x8000000000000000)) becomes
-0x8000000000000000.

expr is also limited to INT64_MAX, but attempts to have non-broken
overflow handling.

> When using strtol() or similar functions, accepting hex typically
> implies accepting octal as well, which causes confusing and
> POSIX-violating results like 010 interpreted as eight.

This is a problem.  strtonum could accept hex but not octal by calling
strtoimax() twice for bases 10 and 16.  Also dehumanized formats like
1k and 1K.  It should also actually accept numbers as input.  1.1e1 if
not I * Pi.

Bruce