Description of problem: When running ansible with command executed in SELinux domain which does not have access to /tmp/.ansible-lock.0, AVC denial is logged. Version-Release number of selected component (if applicable): ansible-1.4.1-1.el6.noarch How reproducible: Deterministic. Steps to Reproduce: 1. Run ansible -c local -i localhost, all -m shell -a "/usr/sbin/semanage fcontext -a -t var_log_t /tmp/test" 2. Check /var/log/audit/audit.log. Actual results: type=AVC msg=audit(1387249253.237:930): avc: denied { write } for pid=11813 comm="load_policy" path="/tmp/.ansible-lock.0" dev=dm-0 ino=1048770 scontext=unconfined_u:unconfined_r:load_policy_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file Expected results: No AVC denial. Additional info:
Clearly there's a filehandle leak in ansible. There is also a leak of that /tmp/.ansible-lock.0 file in the sense that it does not get removed at the end of the execution.
Something like --- /usr/lib/python2.6/site-packages/ansible/callbacks.py.orig 2013-11-19 14:12:32.000000000 -0500 +++ /usr/lib/python2.6/site-packages/ansible/callbacks.py 2013-12-16 22:22:07.989010152 -0500 @@ -79,7 +79,7 @@ path = os.path.join(tempdir, ".ansible-lock.%s" % uid) return path -LOG_LOCK = open(log_lockfile(), 'w') +LOG_LOCK = open(log_lockfile(), 'we') def log_flock(runner): if runner is not None: is needed for the AVC denial thing. I have no idea where the proper place to unlink the lock file would be in the ansible code.
Would you care to file this upstream on github?
(In reply to Kevin Fenzi from comment #3) > Would you care to file this upstream on github? I'd prefer if the packager could do that -- decide what to do, patch in EPEL, file upstream, whatever the best course of action should be. I wouldn't like to get to similar SELinux-related situation we had with cobbler which involved upstream not caring about SELinux and proposing people baked their own policies, rebasing to newer upstream version unnecessarily, and breaking even more SELinux.
Well, you know your example better than I and can try things upstream suggests, but it's no biggie: https://github.com/ansible/ansible/issues/5399 I do not want to diverge from upstream. There is no evidence that I know of that they don't care about selinux. So, lets let them sort things out in the above issue. If you can follow and provide input thats great, if not, I can relay anything from them here. Thanks.
(In reply to Kevin Fenzi from comment #5) > Well, you know your example better than I and can try things upstream [...] > So, lets let them sort things out in the above issue. If you can follow and > provide input thats great, if not, I can relay anything from them here. Thank you for filing the issue. I'm actually just a messenger here as well, filing the bug for some other project. The use case I showed was the smallest I could find but it's not something I'd particularly care about. ;-)
Since the upstream insists that running semanage means non-stock SELinux policy and fall back to the traditional audit2allow mantra, a reproducer which does not involve any SELinux-related command is # ansible -c local -i localhost, all -m shell -a "passwd" localhost | FAILED | rc=1 >> Changing password for user root.New password: Password change aborted. New password: Password change aborted. New password: Password change aborted. passwd: Have exhausted maximum number of retries for service # grep AVC /var/log/audit/audit.log type=AVC msg=audit(1388631051.402:67): avc: denied { write } for pid=7273 comm="passwd" path="/tmp/.ansible-lock.0" dev=dm-0 ino=393222 scontext=unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file # rpm -q ansible selinux-policy-targeted ansible-1.4.1-1.el6.noarch selinux-policy-targeted-3.7.19-231.el6.noarch
I can reproduce it on el6 but I cannot on fedora 20 with ansible 1.4.3 . I can reproduce it with latest git head on el6.
(In reply to Michael Scherer from comment #8) > I can reproduce it on el6 but I cannot on fedora 20 with ansible 1.4.3 . I > can reproduce it with latest git head on el6. Right, on Fedora the problem is not shown because the policy there has allow application_domain_type user_tmp_t : file { ioctl read write getattr lock append } ; Luckily we caught the bug by testing on RHEL 6.
The above issue should be addressed upstream, and the fix will be included in ansible 1.5.
Reopening. Unless there is an immediate plan to rebase ansible in EPEL 6 to 1.5 any time soon, I'd very much prefer to see the patch https://github.com/ansible/ansible/commit/3f90020d6216843f73f829a7c7cb1a3b64d596fc applied to EPEL's build.
Well, 1.5 is due out before the end of the month I think... is that soon enough?
The question No. 1 is: do you even plan to rebase in EPEL 6? This issue is really not a reason for rebase itself, and I have *no* idea what the rebase could break / affect for EPEL people for whom the current version just works. I assume the end-of-month date is 1.5 upstream GA. I assume it can go directly to rawhide. I have no idea how many incompatibilities there might be and if it could go to Fedora 20 or if it would have to wait for 21. If you consider rebase in 20 is possible, it probably should live at least a month in stable 20 before you rebase in EPEL. If you will not want to rebase in 20, you probably want it to be in 21 stable for at least two months before rebasing in EPEL. So we are looking at end of the next month or two months after Fedora 21 GA. I think there is no problem waiting month and a half (but it means 1.5 would go to 20 right after 1.5 GA). On the other hand, waiting six months would seem excessive and in that case I'd really like to ask for patched build in EPEL.
Yes, based on what I currently know I fully intend to update epel to 1.5. Ansible folks are good about warning about depreciated syntax and only removing it several releases later, so I think it should be ok to keep epel up to date. Also most of the depreciations are pretty simple to fix up. yeah, end of month is what I have been hearing for 1.5 upstream. Of course epel updates will need to spend 2 weeks in testing (unless there's sufficent karma to push them to stable sooner). I don't see a need to spend months in testing really. The epel process is 2 weeks, which seems sufficent to me. Anyhow, I guess my inclination is to wait for 1.5 and push that at the end of the month into testing. If you urgently need this patch I'd be happy to make you a scratch build to tide you over until then?
(In reply to Kevin Fenzi from comment #14) > > If you urgently need this patch I'd be happy to make you a scratch build to > tide you over until then? I don't need it urgently. Your plan is sound. Thank you, Jan
ansible-1.5-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/ansible-1.5-1.fc20
ansible-1.5-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/ansible-1.5-1.fc19
ansible-1.5-1.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/ansible-1.5-1.el6
Package ansible-1.5-1.el6: * should fix your issue, * was pushed to the Fedora EPEL 6 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=epel-testing ansible-1.5-1.el6' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0717/ansible-1.5-1.el6 then log in and leave karma (feedback).
I confirm that ansible-1.5-1.el6 addressed the AVC denial.
ansible-1.5-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
ansible-1.5-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
ansible-1.5-1.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.