Bug 1903549

About this issue

What the problem is?
* the main issue is that fapolicyd will deny any access to /var/tmp/ directory for non-root users by default, while ansible requires access into this directory to successfully operate

Why is it a problem to fix this?
1. we can not use fapolicyd trust DB to fix the issue (which would be the ideal way) as the files that ansible executes have randomized paths as they appear within /var/tmp/ directory
2. we can not just allow non-root users to execute files within /var/tmp as it will open a lot of security issues (example: user could just move executable he does not have permission to execute into /var/tmp/ and execute it)

Possible solution:
User who wants to use ansible to execute as a non-root user will need to allow access into /var/tmp/ directory somehow on remote machines. One solution would be to create a group on the remote machines (lets say ansible_group (gid=1000)) and add a rule "allow perm=any gid=1000 trust=1 : dir=/var/tmp/" into /etc/fapolicyd/fapolicyd.rules. Now, any user that is a member of this ansible_group, will have permission to execute files within /var/tmp/, therefore ansible will be able to execute as this user. Ideally the user will be added into this group immediately before ansible executes as this user and will be removed from this group immediately after to minimize the security risk.

Fapolicyd is completely useless anyway.

This is a fully working workaround for getting ansible dynamic facts read as non-root:

[etigulf@repo facts.d]$ cat /etc/ansible/facts.d/firewalld_permanent_zones.fact
#! /usr/bin/env python3
import re
import json
from xml.dom import minidom
import glob
<snip>


Since fapolicyd has a denylist of interpreters it won't run, adding spaces after #! nullifies any attempts to block them.
It means fapolicyd is fully useless garbage created to check a checkbox on some workgroups list of things that needs to be done, but no
practical thought was ever given if it actually works or if it can be worked around in a simple way.

Specifying the interpreter in ansible.cfg to be " /usr/bin/python3" also defeats fapolicyd.

(In reply to ulf.tigerstedt from comment #4)
> This is a fully working workaround for getting ansible dynamic facts read as
> non-root:
> 
> [etigulf@repo facts.d]$ cat
> /etc/ansible/facts.d/firewalld_permanent_zones.fact
> #! /usr/bin/env python3
> import re
> import json
> from xml.dom import minidom
> import glob
> <snip>

I tried exactly this case with fapolicyd-1.0.2-6.el8.x86_64 and it works as expected. I'm getting
$ /etc/ansible/facts.d/firewalld_permanent_zones.fact
-bash: /etc/ansible/facts.d/firewalld_permanent_zones.fact: Operation not permitted

# fapolicyd --debug-deny
...
    rule=12 dec=deny_audit perm=execute auid=0 pid=1346216 exe=/usr/bin/bash : path=/etc/ansible/facts.d/firewalld_permanent_zones.fact ftype=text/x-python
    rule=12 dec=deny_audit perm=open auid=0 pid=1346216 exe=/usr/bin/bash : path=/etc/ansible/facts.d/firewalld_permanent_zones.fact ftype=text/x-python
...

for
# cat /etc/ansible/facts.d/firewalld_permanent_zones.fact
#! /usr/bin/env python3
import re
import json
from xml.dom import minidom
import glob

This bug is going to be migrated.

Contact point for migration questions or issues: rsroka
Guidance for Bugzilla users to test their Jira account or create one if needed:

https://redhat.service-now.com/help?id=kb_article_view&sysparm_article=KB0016394
https://redhat.service-now.com/help?id=kb_article_view&sysparm_article=KB0016694
https://redhat.service-now.com/help?id=kb_article_view&sysparm_article=KB0016774