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.

pleasedesktop
  • 201
  • 4
  • 8
  • You should run dmesg command, not open file /var/log/dmesg – Waveter Mar 01 '16 at 04:00
  • That does not yield any related error message(s) either. I was using `tail -f /var/log/dmesg` to make sure. – pleasedesktop Mar 01 '16 at 04: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 01 '16 at 04: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 01 '16 at 04:31

1 Answers1

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).

pleasedesktop
  • 201
  • 4
  • 8