crun 1.24: regression masked paths return EACCES

[Luap99]

see in podman CI with the new update https://api.cirrus-ci.com/v1/artifact/task/6632208376528896/html/int-podman-fedora-42-rootless-host-sqlite.log.html#t--Podman-run-podman-run-default-mask-test--1

Building from source shows the same problem

$ podman --runtime /home/pholzing/CODE/crun/crun  run --rm quay.io/libpod/testimage:20241011 ls /proc/acpi
ls: can't open '/proc/acpi': Permission denied

Compared to the old crun 1.23.1

$ podman --runtime /usr/bin/crun  run --rm quay.io/libpod/testimage:20241011 ls /proc/acpi

which exits 0 without any error

[giuseppe]

@sohankunkerkar another issue

[giuseppe]

is it selinux related?

[giuseppe]

yeah, we need to fix the selinux policy

[Luap99]

is it selinux related?

Yes it seems so, with --security-opt label=disable added it works

[giuseppe]

@sohankunkerkar I am seeing:

type=AVC msg=audit(1757507956.507:540): avc:  denied  { read } for  pid=20073 comm="ls" name=".empty-directory" dev="tmpfs" ino=1044 scontext=system_u:system_r:container_t:s0:c245,c604 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=dir permissive=0

could you please adjust the policy?

[Luap99]

I See the same denial

Should the mount be created with the right selinux context instead? I doubt we would want to give access to user_tmp_t for the container?

[giuseppe]

I think /run/user/*/crun should be created with container_var_run_t

[Luap99]

Maybe, I have no idea what each context is supposed to represent. We have a similar policy issue with pasta domain transfers as rootless seems to always be user_tmp_t not container_var_run_t containers/podman#26473 (comment)

[giuseppe]

@rhatdan could you please take a look? Should we use container_var_run_t for /run/user/*/crun as we do for /run/crun?

[giuseppe]

opened a PR: #405

[sohankunkerkar]

@sohankunkerkar I am seeing:

type=AVC msg=audit(1757507956.507:540): avc:  denied  { read } for  pid=20073 comm="ls" name=".empty-directory" dev="tmpfs" ino=1044 scontext=system_u:system_r:container_t:s0:c245,c604 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=dir permissive=0

could you please adjust the policy?

As discussed on Slack, this fix is for rootless, since I didn’t encounter the issue while testing on OpenShift.