This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH v2 0/3] posix: Execute file function fixes



> Em 19 de fev de 2016, Ãs 21:13, Paul Eggert <eggert@cs.ucla.edu> escreveu:
> 
>> On 02/19/2016 12:19 PM, Adhemerval Zanella wrote:
>> And it is a regression only if you consider dynamic allocation an alternative,
> 
> It's a regression in that it would break some applications that currently work. An application that is simple (no signal handling, single-threaded, etc.) can invoke programs with many arguments now, but the same application won't work if that patch is installed.
> 

It is debatable since it is using a non-conforming implementation do to so.

> Come to think of it, execlp, posix_spawn, and posix_spawnp can all use malloc, since POSIX does not require them to be async-signal-safe. So you can go back to using malloc for their implementations, when they are given large argument vectors. The only conformance problem here will be execl and execle.

Execlp can not because since it can be used in following vfork. Posix-spawn can, although In match I noted a mmap area with map_stack to provide a better strategy since it may use a large allocated area only in certain cases.

> 
> For these two, I suggest a machine-dependent implementation, with the default being something along the lines of the attached (this is totally untested, I'm just trying to give the gist).
> 
>> A better strategy would be set either hard limits on stack usage in design phase or to focus on enable GLIBC to use a better stack protection mechanism (preferable through compiler assistance).
> 
> The latter sounds like a good idea, but is a bigger project and I doubt whether we'd want to wait for that project to be finished before fixing the exec-family problems in question.
> <execl.c>

I agree, but I also do not see a point in rely on faulty stack allocation mechanisms.

Anyway I see with Joseph comments the only missing point is total mmap area of posix_spawn which sets a hard limit for old shell argument handling and posix_spawnp. We can either document these limit or add a logic to calculate total argument list and mmap an area to accommodate all of it.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]