Re: [PATCHv1] [long] improvements to limit/ulimit API and doc

[Stephane Chazelas <stephane@xxxxxxxxxxxx>]

2020-11-28 03:24:04 +0900, Jun. T:
[...]
> I guess you mean we should reject RLIM_INFINITY, and yes I agree with it.
> How about the patch below (to your v2)?
[...]

It should probably reject RLIM_SAVED_MAX and RLIM_SAVED_CUR like
yash does as well.

[...]
> +	if ((tmp = ret*unit) < ret) {
> +	    *err = "limit out of range";
> +	    return 0;
[...]

I don't think that's a valid check. It would still accept 17EiB
for instance which is the same as 1EiB with rlimt_t === uint64
and greater than 17.

The problem may be better addressed by reviewing overflow
handling everywhere in the code, probably factorising all code
that does parses decimal integer representations, maybe using
strtoll(), etc. I remember seeing a few bug reports here about
overflow handling in arithmetic evaluation, I'm not sure they've
all been fixed. And I'd be surprised if there aren't other
places where this kind of string to number manual handling
without overflow check is done. 

It probably calls for somebody having a thorough look at the
code, and come up with a plan to address the issue globally,
which goes beyond the scope of this rlimit improvement, I say.

-- 
Stephane