This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

What process creates iptables.augnew  Looks like the process that is creating iptables is in an init script?

Or it is a program that does not have SELinux rules written for it.

ps -eZ | grep initrc_t

johanka:~$ ps -eZ | grep initrc_t
johanka:~$

The assumption is that .augnew comes from augeas somehow.

(In reply to comment #6)
> The assumption is that .augnew comes from augeas somehow.    

Hmm,

johanka:~$ rpm -qa \*aug\*
augeas-libs-0.7.1-1.el6.x86_64
johanka:~$ 

I didn't even knew I have such thing on my computer.

It's the netcf library that is calling augeas and causing it to create that file, and that is something valid.

I thought these were all fixed and working? (I even recall (or did I imagine it?) having a discussion about the .augnew files with lutter and dwalsh) Has there been a regression somehow?

I still think some other app created the file.  libvirt should have created it with a label of system_conf_t.

It looks like it was created by an init script and now libvirt is trying to replace it.

Files under /etc/sysconfig/iptables* should be labeled system_conf_t.

Daniel any ideas?

No particular ideas, but I have to question why netcf is changing the iptables rules at all.  IMHO it shouldn't be.

I'm unclear on the details (lutter can provide a better explanation), but when net.bridge.bridge-nf-call-iptables = 1, netcf adds in rules to let traffic pass across bridges.

IMHO that is a bug, because that is a policy decision for the app using netcf to decide upon, that is separate from the task of configuring a bridge. netcf shouldn't make such a policy decision itself, because admins may well actually want to have control over the filtering in such a case.

Reassigning to libvirt?

If you're basing that on Comment 13, I think we should hold the verdict until lutter has his say. (After that, if it's still appropriate to reassign, then it should go to netcf, not libvirt)

(In reply to comment #13)
> IMHO that is a bug, because that is a policy decision for the app using netcf
> to decide upon, that is separate from the task of configuring a bridge. netcf
> shouldn't make such a policy decision itself, because admins may well actually
> want to have control over the filtering in such a case.    

Doesn't that just mimick what libvirt does for private network setups ? What behavior do you prefer ? We could split the iptables mangling into a separate netcf call, though that still wouldn't address the issue in this bug.

The libvirt virtual networking is addressing a specific use case, which is to provide a NAT based network. In that we add a bunch of iptables rules to apply NAT forwarding. This doesn't change /etc/ iptables config files at all, because lokkit doesn't play nicely with custom rules in its configs, so we just directly manage live iptables rules. 

Setting up a physical bridge is a general host configuration task. One of those use cases may be to attach guests to a physical interface. So we should not assume that the admin wants to bypass iptables filtering when configuring a bridge. The default sysctl is net.bridge.bridge-nf-call-iptables=0, so if the admin has changed this to '1', then they likely *want* traffic to be processed by iptables but now netcf has bypassed this. Basically, if the admin wants this bypass they can set it. When configuring bridges normally using ifcfg-XXX files, there is no change in iptables rules, so having netcf change iptables rules when asked for a bridge is not mirroring normal behaviour. I don't particularly see a need to make an explicit API call in netcf for setting up this iptables rule either, since this isn't anything todo with network interface management, it is a separate firewall policy decision.

I'm leaning toward Dan's point of view on this. Perhaps we should have a discussion to come to consensus?

There is another bug addressing the same issue: bug 621499

*** This bug has been marked as a duplicate of bug 621499 ***