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: [log in to unmask]
Web: https://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897