ansible template validation fails with SELinux errors using nsenter connection plugin

[rptaylor]

SUMMARY

Please see all the details and reproduction steps here: ansible/ansible#80269
I thought it seemed like an issue with ansible template validation but an Ansible maintainer suggested it was an issue with the nsenter connection plugin; can you tell where the issue is?

ISSUE TYPE

• Bug Report

COMPONENT NAME

nsenter connection plugin

ANSIBLE VERSION

$ ansible --version
ansible [core 2.12.10]
  config file = /etc/ansible/ansible.cfg
  configured module search path = ['/root/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3.10/site-packages/ansible
  ansible collection location = /root/.ansible/collections:/usr/share/ansible/collections
  executable location = /usr/bin/ansible
  python version = 3.10.10 (main, Feb  8 2023, 00:00:00) [GCC 12.2.1 20221121 (Red Hat 12.2.1-4)]
  jinja version = 3.0.3
  libyaml = True
$ rpm -q ansible
ansible-5.9.0-1.fc36.noarch

COLLECTION VERSION

# ansible-galaxy collection list community.docker

# /usr/lib/python3.10/site-packages/ansible_collections
Collection       Version
---------------- -------
community.docker 2.6.0  

CONFIGURATION

# nothing

OS / ENVIRONMENT

See linked issue.

STEPS TO REPRODUCE

See linked issue.

EXPECTED RESULTS

See linked issue.

ACTUAL RESULTS

See linked issue.

[felixfontein]

I don't really see what the nsenter connection plugin can do about this. @nitzmahone wasn't saying (as I understood it) that this is a problem with the nsenter connection plugin, but with the command line tool nsenter itself (which the plugin is using). The nsenter connection plugin basically prepends the command ansible wants to run with nsenter and some options - see https://github.com/ansible-collections/community.docker/blob/main/plugins/connection/nsenter.py#L103-L113 for what exactly.

[nitzmahone]

Yeah- after thinking about it some more, ultimately this is a really complex halting problem that doesn't necessarily have a generic solution. Having template blindly chcon its tempfile to match the destination file might solve this particular problem, but depending on the system policy and enforcement mode, could just as easily lead to a tempfile that Ansible can no longer access or clean up 😆 .

Off the top of my head, if you know that's not the case, you could add a couple of intermediate steps to template out to a tempfile, chcon the tempfile yourself to match the target, then call iptables-restore on the tempfile, and wrap it in a block with an always to clean up the tempfile afterwards. It's not as handy as having template do it all for you, but should hopefully get you past the hump.

Given how (relatively) difficult testing the SELinux bits are, I'm guessing there wouldn't be a lot of appetite from the core team to add extra knobs to control the labeling of the tempfile inside template/copy/others. This is definitely a nasty confluence of several corner-ish cases- if we come up with a lot more of them, we might need to revisit.

The only reason I mentioned the connection plugin and/or nsenter itself is because I don't have a full understanding of the magic behind SELinux' behavior in containers/namespaces- thinking that perhaps if the same thing worked under eg, the podman plugin, that there was a layer of magic missing by just directly entering the NS.

[rptaylor]

@nitzmahone Thanks for taking another look!

could just as easily lead to a tempfile that Ansible can no longer access or clean up

Good point, I see. Might it be sensible to chcon the pre-validation template file only in the case where serole/setype/etc options of the template module are explicitly specified?
That would provide users a versatile way to work around potential SELinux issues.

That being said, Ansible normally writes everything with "unconfined_u:object_r:admin_home_t:s0" in /root/.ansible (if running as root) so the specific issue in this case must be something about a SELinux transition or something in podman, nsenter or iptables-restore. I tried the -Z option for nsenter but it did not help. I also tried strace of the iptables-restore command but there was nothing interesting. Not sure why the selinux label of the iptables-restore process is different when run with podman and nsenter.

[nitzmahone]

(suggest we move this back to ansible/ansible#80269, which I've reopened)