Closed lukaszachy closed 9 months ago
@lukaszachy I successfully reproduced the issue, so will try to look into it. Do you think it would make sense to add some kind of test to upstream testsuites that would cover this use-case? Or is it, in your opinion, sufficient to check it manually from time to time?
New tmt is able to check it for you, https://tmt.readthedocs.io/en/stable/spec/tests.html#check
Whether it's worth occasional false negatives I'm not sure. Downstream it is checked (and waived) regularly.
From podman docs[1]:
The z option tells Podman that two or more containers share the volume content.
As a result, Podman labels the content with a shared content label. Shared volume
labels allow all containers to read/write content.
The Z option tells Podman to label the content with a private unshared label.
Only the current container can use a private volume.
We use Z
and create two containers in this testcase with the same volume.
Fix can be either to use z
instead of Z
or create separate volume for second container. I vote for the second option. Will create PR for that if no one disagrees :).
However, if this causes in downstream some bigger issues (need of repetitive waiving, etc.) we can go for more systematic change.
Container platform
Podman/Docker
Version
All postgresql images, reproducer with the postgresql 15 on c9s
OS version of the container image
RHEL 7, RHEL 8, RHEL 9, CentOS 7, CentOS Stream 8, CentOS Stream 9, Fedora
Bugzilla, Jira
No response
Description
During the test plenty of
are raised. I'm not sure why selinux complains as the volume-dir is bind as
:/var/lib/pgsql/data:Z
. Maybe test should set the correct context?Reproducer
Run
OS=c9s VERSION=15 TESTS=run_change_password_test IMAGE_NAME=quay.io/sclorg/postgresql-15-c9s test/run
thenausearch -m avc -i -ts recent