avc: denied raised during the `run_change_password_test`

[lukaszachy]

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

----
type=PROCTITLE msg=audit(11/20/2023 10:56:45.531:510) : proctitle=postgres: logger  
type=SYSCALL msg=audit(11/20/2023 10:56:45.531:510) : arch=x86_64 syscall=write success=no exit=EACCES(Permission denied) a0=0x7 a1=0x55b294c64b80 a2=0x63 a3=0x1 items=0 ppid=17233 pid=17368 auid=root uid=unknown(26) gid=unknown(26) euid=unknown(26) suid=unknown(26) fsuid=unknown(26) egid=unknown(26) sgid=unknown(26) fsgid=unknown(26) tty=(none) ses=13 comm=postgres exe=/usr/bin/postgres subj=system_u:system_r:container_t:s0:c77,c283 key=(null) 
type=AVC msg=audit(11/20/2023 10:56:45.531:510) : avc:  denied  { append } for  pid=17368 comm=postgres path=/var/lib/pgsql/data/userdata/log/postgresql-Mon.log dev="vda1" ino=234338 scontext=system_u:system_r:container_t:s0:c77,c283 tcontext=system_u:object_r:container_file_t:s0:c134,c652 tclass=file permissive=0

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 then ausearch -m avc -i -ts recent

[zmiklank]

@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?

[lukaszachy]

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.

[zmiklank]

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.

[1] https://docs.podman.io/en/v4.4/markdown/podman-run.1.html#volume-v-source-volume-host-dir-container-dir-options