On Thu, Apr 09 2020, Marc Espie <[email protected]> wrote:
> On Thu, Apr 09, 2020 at 02:44:14PM +0200, Jeremie Courreges-Anglas wrote:
>> On Thu, Apr 09 2020, Jeremie Courreges-Anglas <[email protected]> wrote:
>> > find(1) uses ARG_MAX to compute the maximum space it can pass to
>> > execve(2). This doesn't fly if userland and the kernel don't agree, as
>> > noticed by some after the recent ARG_MAX bump.
>> >
>> > --8<--
>> > ritchie /usr/src/usr.bin/find$ obj/find /usr/src/ -type f -exec true {} +
>> > find: true: Argument list too long
>> > find: true: Argument list too long
>> > find: true: Argument list too long
>> > ^C
>> > -->8--
>> >
>> > While having the kernel and userland out of sync is not a good idea,
>> > making find(1) more robust by using sysconf(3) is easy. This is what
>> > xargs(1) already does.
>> >
>> > ok?
>>
>> Committed, thanks.
>>
>> > PS: a followup diff will take into account the space taken by the
>> > environment
>>
>> Right now we don't account for the space used by the environment.
>> We get lucky either because of the 5000 max args limit or because
>> environment size usually fits in the 4096 bytes safety net.
>>
>> The diff below uses the same approach as xargs(1).
>> While here, tweak the message in case of (unlikely) sysconf(3) failure.
>
> You drop a bit of the comment in find, specifically the 4K stuff.
>
> I would probably restore it.
If you're thinking about this comment in xargs.c:
/*
* POSIX.2 limits the exec line length to ARG_MAX - 2K. Running that
* caused some E2BIG errors, so it was changed to ARG_MAX - 4K. Given
* that the smallest argument is 2 bytes in length, this means that
* the number of arguments is limited to:
*
* (ARG_MAX - 4K - LENGTH(utility + arguments)) / 2.
*
* We arbitrarily limit the number of arguments to 5000. This is
* allowed by POSIX.2 as long as the resulting minimum exec line is
* at least LINE_MAX. Realloc'ing as necessary is possible, but
* probably not worthwhile.
*/
I did not drop it since it was not there in the first place. (:
The comment is here since rev 1.1 and doesn't give a rationale for the
4K reserved space, except "it worked when I tested". The rest of the
comment is about the maximum number of arguments. I think the comment
should be improved before spreading it.
> Note that there is an explanation for the overflow in the kernel code:
> MAXINTERP + MAXPATHLEN
>
> exec does not reallocate args for scripts, but requires the extra space to
> set things up.
Thanks for pointing this out. As discussed with deraadt@ it's probably
not a good idea to mimic too closely the algorithm in the kernel.
However if MAXINTERP+MAXPATHLEN quirk is the explanation behind the 4K
space reserve, we could turn that knowledge into better code.
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
