0

If I try to run the following command in my lxc/lxd Ubuntu 14.04 amd64 container:

iptables -A OUTPUT -p tcp -m owner --uid-owner 0 -m tcp --dport 80 -j ACCEPT

I get the following error message:

iptables: Invalid argument. Run `dmesg' for more information.

...but /var/log/dmesg doesn't get any extra output.

I'm sure that iptables rule is valid because it works in the lxc/lxd host and in other machines. The part that seems to be at fault is the owner part, i.e. if I run this:

iptables -A OUTPUT -p tcp -m tcp --dport 80 -j ACCEPT

...it works fine.

This seems like a bug in lxc to me, but is there any way I can investigate it further?

Edit 1

I built iptables from source with debug flags and then traced through the execution. This led me to the iptables-standalone.c file, in which the:

int iptc_commit(struct xtc_handle *handle);

...function is returning an EINVAL error code. Problem is I can't track down the source for that function. It seems to be located in the libip4tc.so shared library, but I can't track down the source for that library.

If someone knows where the source, I would appreciate it if you could let me know.

Edit 2

Refer to this lxc GitHub issue I created which paints more of a picture. I am going to give up, only because the work is too far-reaching for me to take on when I can just work around the issue by avoiding "owner" matched iptables rules in containers.

  • You should run dmesg command, not open file /var/log/dmesg – Waveter Mar 1 '16 at 4:00
  • That does not yield any related error message(s) either. I was using tail -f /var/log/dmesg to make sure. – pleasedesktop Mar 1 '16 at 4:11
  • You can use command iptables --version to compare version between iptables inside lxc and iptables of the normal host. I think this error related to version of iptables – Waveter Mar 1 '16 at 4:24
  • They are exactly the same version and the sha256sum of both /sbin/xtables-multi match. It's a problem with lxc, I'm going to build from source on the container and debug the problem myself, to find the root cause. – pleasedesktop Mar 1 '16 at 4:31
0

All you have to do is set the "security.privileged" configuration of the container to "true", as it defaults to "false".

I.e. refer to this and look for that "security.privileged" configuration.

I'm not exactly sure what changing this config does, so beware and research yourself, but I think it just grants the container more privileges with regard to controlling the shared kernel (shared between host and container).

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.