Author izbyshev
Recipients Yonatan Goldschmidt, gregory.p.smith, izbyshev, koobs, pablogsal, ronaldoussoren
Date 2020-10-15.05:15:33
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1602738934.26.0.905152490672.issue35823@roundup.psfhosted.org>
In-reply-to
Content
Well, much later than promised, but I'm picking it up. Since in the meantime support for setting uid/gid/groups was merged, and I'm aware about potential issues with calling corresponding C library functions in a vfork()-child, I asked a question on musl mailing list: https://www.openwall.com/lists/musl/2020/10/12/1

So, it seems we'll need to fallback to fork() if set*id() is needed, which is in line with our previous discussion about avoidance of vfork() in privileged processes anyway.

I'm also discussing -Wclobbered warnings with a GCC developer. I wouldn't like to restructure code just to avoid GCC false positives, so currently I'm leaning towards disabling this warning entirely for subprocess_fork_exec() and documenting that arbitrary stores to local variables between vfork() and child_exec() are not allowed due to stack sharing, but we'll see if a better solution emerges.
History
Date User Action Args
2020-10-15 05:15:34izbyshevsetrecipients: + izbyshev, gregory.p.smith, ronaldoussoren, koobs, pablogsal, Yonatan Goldschmidt
2020-10-15 05:15:34izbyshevsetmessageid: <1602738934.26.0.905152490672.issue35823@roundup.psfhosted.org>
2020-10-15 05:15:34izbyshevlinkissue35823 messages
2020-10-15 05:15:33izbyshevcreate