Or you could have 2 dry runs. One to merely see that it won't head into
interactive mode
and a second one to start the unveiling directly in fetch.c. Unless unveil
itself will
have too many entries!
-Luke
On Wed, Jun 3, 2020 at 11:12 AM Luke Small <lukensm...@gmail.com> wrote:
> I figure if it took up that much stack space from before, it'd start
> needing to
> dang near run the stack into on-disk virtual memory anyway. At that point,
> it'd perhaps be a better design choice to break up your ftp calls into
> slightly
> smaller chunks to avoid massively poor performance, yeah? LOL
>
> If you're really worried about it, perhaps you could put in a goto which
> jumps
> over the offending part, when argc is so massive that
> it would cause such a thing...Hmmm.
> -Luke
>
>
> On Wed, Jun 3, 2020 at 10:39 AM Theo de Raadt <dera...@openbsd.org> wrote:
>
>> You really don't get it.
>>
>> + unveil_list = calloc(2 * argc, sizeof(char*));
>>
>> Imagine argc is 10000.
>>
>> + for (i = 2 * argc - 2; i >= 0; i -= 2) {
>> + if (unveil_list[i]) {
>> + if (unveil(unveil_list[i], "r")
>> == -1)
>> ...
>> + if (unveil_list[i | 1]) {
>> + if (unveil(unveil_list[i | 1],
>> "cw") == -1)
>> + err(1, "unveil");
>> ...
>>
>>
>> E2BIG The addition of path would exceed the per-process
>> limit for unveiled paths.
>>
>>
>> Great, under fairly normal usage ftp aborts with an error.
>>
>> Since you start with up to 8 others, it looks like this limit is easily
>> hit at around 120 filenames.
>>
>> So ftp simply fails to perform the task it is designed for.
>>
>> Your proposal is to break the command.
>>
>>
