Description of problem: Restarting tripleo_redis.service causes an AVC if SElinux is enforced: type=AVC msg=audit(1595596546.420:1482): avc: denied { unlink } for pid=1 comm="systemd" name="redis.sock" dev="tmpfs" ino=419874 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:container_file_t:s0 tclass=sock_file permissive=0 Version-Release number of selected component (if applicable): How reproducible: Deploy Redis via TripleO with SElinux enforced, and try to restart tripleo_redis.service with systemctl. Steps to Reproduce: 1. Deploy Redis via TripleO 2. systemctl restart tripleo_redis.service Actual results: AVC in audit.log Expected results: No AVC Additional info:
The patch looks correct though I'd like to see Cedric's input on it first as the init_t part is strange. I noticed Cedric brought this up on #tripleo: deployment/database/redis-container-puppet.yaml: ExecStartPre: /bin/chcon -t container_file_t /run/redis and you said removing it made no difference. Just to double-check, could it be that /run/redis wasn't restored to its original context before trying again? ($ restorecon -F /run/redis) (result can be confirmed with ls -Z /run/redis). It would be good to reproduce the error in permissive mode and attach the permissive audit.log to the bug as well.
Let's start by dropping this block first: https://github.com/openstack/tripleo-heat-templates/blob/master/deployment/database/redis-container-puppet.yaml#L170-L172 It's redundant and therefore useless, and instruct systemd to create AND remove /run/redis on service start and stop. More than probably the root cause of the issue - this location is managed by tmpdir, and the container has the :z flag, so both ExecStartPre and RuntimeDirectory are useless.
Wallaby/osp-17? Modified without Fixed In Version? Care to update it? Thanks :).
The patch resolving this was a THT patch -> https://review.opendev.org/743149 , the openstack-selinux PR is closed :) I can't see the patch due to opendev maintenance though... but since it merged in July, I picked a recent THT NVR for 17 instead. Hopefully that works for you Cedric, otherwise let me know and I can try and dig out something more precise.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Release of components for Red Hat OpenStack Platform 17.0 (Wallaby)), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2022:6543