On Fri, Sep 14, 2012 at 4:45 AM, Erik Cederstrand <[email protected]> wrote: > Den 14/09/2012 kl. 13.03 skrev Ivan Voras <[email protected]>: > >> On 14/09/2012 09:49, Erik Cederstrand wrote: >>> Hello hackers, >>> >>> I'm looking through the Clang Analyzer scans on >>> http://scan.freebsd.your.org/freebsd-head looking for false positives to >>> report back to LLVM. There are quite a list of reports suggesting to change >>> vfork() calls to posix_spawn(). Example from /bin/rpc: >>> http://scan.freebsd.your.org/freebsd-head/bin.rcp/2012-09-12-amd64/report-nsOV80.html#EndPath >>> >>> I know nothing about this but I can see fork and posix_spawn have been >>> discussed on this list previously. Is this a legitimate warning (in this >>> case and in general in FreeBSD base)? >> >> Currently (on 9-stable at least), posix_spawn() is implemented as a >> wrapper around vfork(), so I doubt replacing one with the other would do >> much. > > The analyzer added this warning in January. The release notes link to this > explanation: > https://www.securecoding.cert.org/confluence/display/seccode/POS33-C.+Do+not+use+vfork() > > I guess this is the important part: > > "Because of the implementation of the vfork() function, the parent process is > suspended while the child process executes. If a user sends a signal to the > child process, delaying its execution, the parent process (which is > privileged) is also blocked. This means that an unprivileged process can > cause a privileged process to halt, which is a privilege inversion resulting > in a denial of service." >
Isn't the important part the previous paragraph, which said that some older versions of Linux had the problem? The entire thing reads that the issue comes from an idiom of vfork(), setuid(), then exec, which is both undefined and would be specific to only some *uses* of vfork(), not the implementation. The whole thing isn't worded terribly usefully; e.g. it doesn't explain if it was only Linux that had an issue, which version of Linux is fixed, whether normal code that went straight from vfork() to exec() was fine, etc. Cheers, matthew _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[email protected]"
