[Libguestfs] [libnbd PATCH v3 09/29] lib/utils: introduce async-signal-safe execvpe()

[Laszlo Ersek]

On 2/22/23 22:50, Eric Blake wrote:

> Or that glibc has taken special pains to make reliance on certain
> AS-unsafe functions (namely, malloc() and getenv()) "safer" in
> practice, despite permission from POSIX allowing glibc to throw
> caution to the wind and claim deadlocks to be the progammer's bug
> rather than glibc's.  The fact that documentation does not match
> reality is indeed disheartening, but this may be a good time to open
> up bug requests to the documentation team(s) that can improve it for
> the next reader.
> 
> Deadlock avoidance is one of the harder topics in computer science;
> I'm glad that glibc is going out of their way to make fork()/exec()
> work in more cases than promised by POSIX, but it also means a lot of
> programmers don't realize the complexities that glibc is solving on
> their behalf, and how their code may not be portable to a lesser libc.

I've filed:

https://bugzilla.redhat.com/show_bug.cgi?id=2172869


>>> https://www.austingroupbugs.net/view.php?id=1440 is where it came up
>>> in the Austin Group.  Basically, having system("+s") be _required_ to
>>> invoke ["/path/to/sh", "-c", "+s"] is risky - "+s" is ambiguous
>>> between being the name of a real script and being a shell option

[...]

OK, now I understand the point about the particular invocation being
"required" versus just "permitted". If it gets relaxed to "permitted",
then implementations may (but do not have to) improve their system() and
similar functions to insert "--".

An implementation that did not react to such a potential relaxation of
requirements would not become non-conforming, so this is effectively
about accommodating a wider range of Quality of Implementation.

I think I'll stick with the execvpe() patch as it is, for the time being.

Thanks!
Laszlo