+-- On Tue, 2 Jul 2019, P J P wrote --+
| | -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?
|
@Dan:...ping!?
--
Prasad J Pandit / Red Hat Product Security Team
47AF CE69 3A90 54AA 9045 1053 DD13 3D32 FE5B 041F
