[grsec] Fwd: Re: Bug#336461: debhelper: dh_fixperms - xargs: chown: Argument list too long

[pageexec at freemail.hu]

On 9 Nov 2005 at 3:49, Bernd Zeimetz wrote:
> this looks much better now. xargs works again in the case I had the problem 
> with it originally.
> From the source of xargs:
> 
>   /* IEE Std 1003.1, 2003 specifies that the combined argument and
>    * environment list shall not exceed {ARG_MAX}-2048 bytes.  It also
>    * specifies that it shall be at least LINE_MAX.
>    */
> 
> and they take care of that rule.

interesting, where exactly does that quote come from? in my copy of
the spec i can find only this:

9565 The number of bytes available for the new process’ combined argument and environment lists is
9566 {ARG_MAX}. It is implementation-defined whether null terminators, pointers, and/or any
9567 alignment bytes are included in this total.

and

28305 The number of bytes available for the child process’ combined argument and environment lists
28306 is {ARG_MAX}. The implementation shall specify in the system documentation (see the Base
28307 Definitions volume of IEEE Std 1003.1-2001, Chapter 2, Conformance) whether any list
28308 overhead, such as length words, null terminators, pointers, or alignment bytes, is included in
28309 this total.

note 'any alignment bytes'. now i don't know how 'alignment' is defined
in this context (in PaX it'd be up to PAGE_SIZE), but at least it means
that userland can't really assume a constant/fixed amount of actually
usable bytes (which is what xargs does). so my guilt seems to be only
that i haven't documented it in my 'system documentation' ;-).

> So I think your workaround should fix it, or 
> did I calc something wrong!?

don't know what you calculated ;-), but my fix is basically to keep
ARG_MAX but account for the randomization induced reduction in actual
usable (allocated) space by adding an extra page. 32 pages = 128k (at
least on i386), which is where ARG_MAX comes from. i could have also
changed ARG_MAX to be 124k, but that would require userland recompilation,
it's much simpler to add an extra page instead to the initial stack.

> Thanks a lot for the patch, please let me know if you're going to 
> change/test/patch anything else related to this problem.

that was it, nothing else needs to change i think.