On 2017-02-10 05:01, Konstantin Olchanski wrote:
Reporting more selinux borkage. (to remember main selinux feature is
commands
executed from root shell work differently from commands run by cron
or sshd & co. Clearly this is introduced to simplify testing stuff).
This time, broken is letsencrypt certificate renewal using certbot.
"certbot renew" works just fine from command line, but not from
a cron job: selinux prevents httpd access to files
/var/lib/letsencrypt.
(BTW, the certbot packages does not even include any cron jobs,
"manual automatic renewal", please patent it quick!)
Bug reports for this:
https://community.letsencrypt.org/t/certbot-via-cron-writes-files-unreadable-by-apache-selinux-centos-7/24792
(auto-closed after 30 days, no old stale bugs in that operation!)
https://bugzilla.redhat.com/show_bug.cgi?id=1385167
https://bugzilla.redhat.com/show_bug.cgi?id=1377312
This wouldn't be accepted as an upstream bug - mainly because its not a
RHEL shipped package. It could be lodged against EPEL, but there'd be no
priority for anyone to fix anything.
Since I will learn selinux after I learn ldap after our current
high-priority
project ships to CERN in September, I do not see any solution other
than disabling
selinux until this is fixed (presumably by the EPEL package certbot
incuding
correct selinux policy kludges). BTW, on the machines where selinux is
disabled
due to the ZFS bug, letsencrypt renewal works just fine.
I would approach it by putting selinux in permissive mode. From the CLI
'setenforce 0' and to make permanent, edit /etc/sysconfig/selinux.
From there, use the setroubleshoot-server package to use audit2allow and
/ or sealert to create a policy to allow it.
I'm thinking of writing up a blog post on my site regarding an automatic
troubleshooter for selinux, but I'm not quite there yet.
--
Steven Haigh
Email: [email protected]
Web: https://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
