Hello Dan, +-- On Tue, 2 Jul 2019, Daniel P. Berrangé wrote --+ | The original code was passing through to the shell to handle the case | where the user requested | | -netdev bridge,helper="/path/to/helper myarg otherarg" | | In theory any parts could contain shell meta characters, but even if | they don't we'll have slightly broken compat with this change.
I wonder if anybody uses it like that. Because of the 3 arguments that qemu-bridge-helper takes --use-vnet --fd=sv[1] --br=bridge only bridge name is supplied by user; Which is anyway comming without 'helper' having to include '--br=bridge' argument, as is looked for before shell invocation if (strstr(helper, "--br=") == NULL) { snprintf(br_buf, sizeof(br_buf), "%s%s", "--br=", bridge); } '--br=bridge' has limited scope to use shell meta characters, ie. other than space(' ') and tab('\t'). | The QEMU man page has never documented that you can pass a command | and args, which get sent via the shell though. It only ever documented | the helper arg as being a plain qualified binary path. | | So the question is how strictly we need to consider compatibility. | | The "if it isn't documented it never existed" option is to use your | patch here. We don't know if "/path/to/helper arg1 arg2" usage exists in practice. And considering user would still be able to supply 'bridge' argument, I wonder if we are breaking compatibility. | The safest option is to put in a place a deprecation saying we'll | drop use of shell in future, only implementing the aggressive | option in a later release. ie. for Qemu > v4.0.0? How do we do this? | Perhaps from your POV, the easy thing is to avoid this entire | question - just leave the code calling shell, but switch to | g_strdup_printf instead of snprintf. Okay, this will be for Qemu <= v4.0.0? Thank you. -- Prasad J Pandit / Red Hat Product Security Team 47AF CE69 3A90 54AA 9045 1053 DD13 3D32 FE5B 041F