fix: Apply SELinux security context after moving to mail-state#3890
Conversation
|
LGTM 👍 I am not very firm with SELinux. Can this introduce any unwanted side-effects/problems on systems, not using SELinux security context? |
I've added ignoring the exit status (in case the scripts use If the system supports SELinux but it's "Permissive" instead of "Enforcing", the |
|
Thanks, fixed! |
d37f2de to
3d778b4
Compare
|
@polarathene Just curious, did you assign me to update my branch? Just did and unassigned myself again, hope that's ok. |
|
I re-assigned you; this makes finding PRs for maintainers easier. It's just a visibility-thing, not strictly relevant to any actions that we need you to take. |
polarathene
left a comment
There was a problem hiding this comment.
LGTM! Like @casperklein I don't have the SELinux expertise to provide much feedback.
I'd merge but not sure if @georglauterbach wants to block for their own review.
|
Go ahead and merge, not time to review this one :) |
Description
After
setup.d/mail_state.shmoves files/dirs from the container itself to/var/mail-state, they retains their SELinux security context labels, which are bound to the current container. When using named volumes, this leads to the files/dirs becoming inaccessible.This PR lets the setup script apply the security context from the mail-state directory after moving, so they are still accessible when a new container is created that re-uses a named volume. The result is that the moved files will have the same security context as if they were created by the script.
This also explains the issue only occurs with the mail-state volume. In the other volumes only new files are created, instead of files being moved.
Fixes #3887
Type of change
Checklist
docs/)CHANGELOG.md