after commit 80d8bfaac9e2430d710084a10ec78e68bd61e6ec "iptables: insist that 
the lock is held."
it became impossible restore to configure iptables from child user namespace:

kirill@:~/criu$ unshare -U -m -p -f -n --map-root-user --mount-proc
root@:~/criu# iptables -A INPUT -s -j DROP
Fatal: can't open lock file /run/xtables.lock: Permission denied

iptables running inside init user ns/init net ns create the file with 0600, and 
are not able to open it.

It seems a good solution could be to use per net ns file to flock it,
and this would provide more scalability. But the problem is there is
not good one to choose. It could be someone like /proc/self/net/netfilter,
but /proc fs is made in the way, that /proc/X/net/netfilter and 
have different inodes, despite X and Y refer to the same net ns. It seems,
the only good candidate is /proc/self/ns/net, but it's too generic file
to lock it (it may be interesting not only for iptables). Not sure, we can use 

So, it looks like the solution may be to create the file with 0666 mode by 
This does not lose security, as it's only iptables agreement, and evil person
could just compile iptables without this file lock check. How do you think 
about all this?

diff --git a/iptables/xshared.c b/iptables/xshared.c
index 06db72d4..fbbe9495 100644
--- a/iptables/xshared.c
+++ b/iptables/xshared.c
@@ -254,7 +254,7 @@ static int xtables_lock(int wait, struct timeval 
        time_left.tv_sec = wait;
        time_left.tv_usec = 0;
-       fd = open(XT_LOCK_NAME, O_CREAT, 0600);
+       fd = open(XT_LOCK_NAME, O_CREAT, 0666);
        if (fd < 0) {
                fprintf(stderr, "Fatal: can't open lock file %s: %s\n",
                        XT_LOCK_NAME, strerror(errno));


Reply via email to