Re: [Qemu-devel] [PATCH v3 3/3] net: tap: refactor net_bridge_run_helper routine

[P J P]

  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