Re: [PATCH 1/2] posix: execvpe cleanup

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 25-01-2016 12:37, Andreas Schwab wrote:
> Adhemerval Zanella <adhemerval.zanella@linaro.org> writes:
> 
>> For default process spawn (script file without a shebang), stack
>> allocation is bounded by NAME_MAX plus PATH_MAX plus 1.
> 
> Both NAME_MAX and PATH_MAX depend on the directory and may not be
> defined if there is no system wide limit.
> 
> Andreas.
> 

It is a compromise of allowing multiple different limits for each FS
and limiting potentially issues (stack overflow).

The first option would be just impose no limit on such variables 
(the PATH environment variable and the file argument size) and do
stack/alloca allocations.  This is what uclibc does for MMU targets
(for non-mmu it uses a mmap/unmap).  A side note is uclib does 
enforce a maximum file size returning ENAMETOOLONG for such case.

The second option would be to enforce some minimum limits based on default 
PATH_MAX and NAME_MAX.  This is what musl and BSDs (open, free, net) 
do. This have the downside of not really work on every different
FS we have out there, as you said.

Finally, the third options would is just to drop this patch and rework
the  posix_spawnp path to mimic this new execvpe behaviour with some
memory allocation limits by stack/alloca. I do not see it is as a good 
approach since it is basically a code duplication for an internal
function that can be provided for both implementations and for a QoI
execvpe should not use malloc (to avoid memory leak in vfork/clone
case).

Due GLIBC behaviour of allowing the script call in case of a script
without shebang, a possible stack overflow can happen (since exevpe
must re-construct the arguments for the shell script call). So I am
not sure if first or second option should be the best.