I have a cell modem connected to my server that I want to use as a means to get notification emails out when the landline dies.

To nicely separate normal network access and this exceptional cell modem access, I created a network namespace and created the network device in there as the only device. To have a program use the cell modem I simply use ip netns exec.

The wrinkle is that I want to allow any user to run any program they wish in the namespace, but netns exec requires root. My solution is as follows:


/bin/ip netns exec oob \
    /usr/bin/sudo -u "#$SUDO_UID" -g "#$SUDO_GID" /bin/sh -c "$cmd_line"


ALL ALL=NOPASSWD: /usr/local/sbin/_oob_shim

I figure the only way to run the shim without already being root or knowing the root password is through sudo, and I can trust sudo to set $SUDO_UID and $SUDO_GID to the right values.

Am I opening myself up to significant risk? Or, should I say am I missing any obvious caveats?

1 Answer 1


The only bug I see with your code is that you're running the user's command unnecessarily through sh -c when you should just run it directly. Running it through sh -c buys you nothing but it destroys quoting that the user originally put into the command. For example, try this:

sudo /usr/local/sbin/_oob_shim ls -l "a b"

should list a file called a b inside the context of the namespace but instead it lists two files called a and b.

sudo /usr/local/sbin/_oob_shim ls -l "*"

should list a file called * (literal asterisk), fails for the same reason.

So it should look like this instead:

/bin/ip netns exec oob \
    /usr/bin/sudo -u "#$SUDO_UID" -g "#$SUDO_GID" -- "$@"

Makes the script simpler to boot!

Another point I can make is that although in this case the bug was just a functionality bug, not a security bug, one is always suspicious when auditing security-sensitive code and finding that it runs things through shells because that's almost always a problem.

Finally, the user's supplementary groups will not be propagated into the namespace (they get only their uid and main gid), but that doesn't seem like a huge problem and fixing that is not trivial.

Other than that, it looks good to me.

  • 1
    Using the shell didn't quite buy me nothing, it prevents sudo /usr/local/sbin/_oob_shim -u root cat /etc/shadow which is a hole in your suggested version. You're totally right about the quoting though, I'll start with sudo -u "#$SUDO_UID" -g "#$SUDO_GID" -- "$@" and keep looking for security holes. Mar 13, 2015 at 16:14
  • You're so right about the user being able to override options with my version. I totally missed that. Your solution of using -- if of course correct. I'd better edit that in to my answer!
    – Celada
    Mar 14, 2015 at 9:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.