IpNetnsExecFilter does not qualify the path of nested commands

I suppose we may need to extend IpNetnsExecFilter to actually qualify the path for the ip netns exec wrapped executable.

I will look at that tomorrow morning.

There is a similar bug, in this case for the KillFilter: https://bugs.launchpad.net/oslo.rootwrap/+bug/1394279

I was talking to ttx, and a possible solution for this would be to modify the secure_path of sudo config
https://bugs.launchpad.net/oslo.rootwrap/+bug/1394279/comments/1

Maru, are we able to alter the sudo configuration for the functional testing case?

Not sure if we're targeting here too the ability to run the functional tests in the development environment
without doing an install to the system.

Fix proposed to branch: master
Review: https://review.openstack.org/152902

Change abandoned by Miguel Angel Ajo (<email address hidden>) on branch: master
Review: https://review.openstack.org/152902
Reason: We found a workaround to do this, so this is left abandoned as reference for just in case we need to take this path back.

The workaround was including PATH=$(external_sudo_path):$PATH in front of the exec, and adding a rootwrap rule to allow it.

So the final execution is...

sudo rootwrap /etc/my-rootwrap-filters PATH=/my/external_path:$PATH my-exec params

and we're able to inject a path.

Our use case is testing, so we're not very worried about security implications, we could understand other use cases may be more worried and may need to work on a proper rootwrap fix.

I discovered an additional workaround that may be considered more secure and doesn't require any patching.

In the neutron sudoers file, I added a secure_path that included my installation bin directory:

  Defaults:neutron secure_path = /opt/openstack/neutron/bin:/sbin:/bin:/usr/sbin:/usr/bin

Setting the path in the sudo invocation doesn't work if the target host sets secure_path (can't set the path in that case). The neutron functional setup already sets secure_path as suggested in the previous comment:

https://github.com/openstack/neutron/blob/master/tools/configure_for_func_testing.sh#L195

This is a hacky solution at best, and rootwrap should really be fixed to be able to resolve a command targeted for nested (ip netns exec) execution within its exec_dirs search path. Since non-nested commands are already resolved in this manner, I don't think it can be considered a potential security problem.

Thanks for the clarifications,

I would work in it if we find agreement from the project cores, it sounds reasonable to me to have it fixed.

Fix proposed to branch: master
Review: https://review.openstack.org/185250

Change abandoned by stephen-ma (<email address hidden>) on branch: master
Review: https://review.openstack.org/185250

We ran into this problem yesterday.

On our compute host we have venvs for both neutron and nova, and under
/etc/sudoers.d/ we had a file for each projects rootwrap. And in those files
we specified a secure path.

/etc/sudoers.d/neutron-rootwrap
Defaults secure_path="/opt/openstack/neutron/venv/bin:..."
neutron ALL=(root) NOPASSWD: /opt/openstack/neutron/venv/bin/neutron-rootwrap /etc/neutron/rootwrap.conf *

/etc/sudoers.d/nova-rootwrap
Defaults secure_path="/opt/openstack/nova/venv/bin:..."
nova ALL=(root) NOPASSWD: /opt/openstack/nova/venv/bin/nova-rootwrap /etc/nova/rootwrap.conf *

But only one of those 'secure_path' takes preference, in our case nova which
meant that 'neutron-ns-metadata-proxy' was out of our path again.

Wouldn't it just be better if we just set the environment PATH to the
exec_dirs, since that's where we'll be searching for the executables.
This would also result in less places to maintain your paths.

oslo_rootwrap/wrapper.py
if config.has_option("DEFAULT", "exec_dirs"):
  self.exec_dirs = config.get("DEFAULT", "exec_dirs").split(",")
  # Replace PATH with exec_dirs if specified
  os.putenv("PATH", ":".join(self.exec_dirs))