[plug] xargs, "Argument list too long" (OT-ish)

[Craig Ringer]

>>I don't think it'd really be something you'd need to limit per-user or 
>>per-process like ulimit allows. That'd add another overhead to each 
>>process' info as well. I'd be more inclined to think a /proc or /sys 
>>(??) interface might be the way to do it.
> 
> So then the root user would be giving all users and all processes the
> ability to use more memory for argument lists just so that the root user
> can mkisofs? And once this change has been made, is it going to be left
> like that? What if another admin logs in and changes it again for their
> own purposes, interfering with what you're doing? And what if it doesn't
> work because there is some other process limit?

True, but then you are looking at another thing that has to be /handled/ 
on a per-process basis, and takes up space in the process table too. Is 
it really useful to be able to control this per process in enough cases?

I think it might be to avoid allocating oodles of RAM to hold unused 
extra arg space, unless we can just dynamically allocate enough RAM to 
store that particular set of args. Since most likely per-process arg 
size limits would require that ability for their implementation, I doubt 
they'd be really useful. They might help prevent a DoS attacks like echo 
`cat /dev/zero` from working, but I think those attacks could be solved 
by setting a per-user RSS limit with ulimit (the shell would die when it 
ran out of RAM to store the command in, before ever passing it to execv() ).

As for the issue of a global change for only one user - yeah, that is an 
issue. The ideal solution would be dynamically allocating arg memory 
depending on arg length. The /proc or /sys interface method would only 
be a small step up from a hardcoded value in the kernel, allowing it to 
be easily changed on the fly and in pre-compiled vendor kernels. Its far 
from perfect but better than what we have now.

Craig Ringer

> Maybe time to submit a feature request for mkisofs :) (i.e. accept paths
> from a file containing one path per line or something, if that's the
> problem.)
>