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 <[email protected]> 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. > >
