Description of problem: Start rootless containers with podman-compose. SELinux is preventing pasta.avx2 from 'create' accesses on the file rootless-netns-conn.pid. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that pasta.avx2 should be allowed create access on the rootless-netns-conn.pid file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'pasta.avx2' --raw | audit2allow -M my-pastaavx2 # semodule -X 300 -i my-pastaavx2.pp Additional Information: Source Context unconfined_u:unconfined_r:pasta_t:s0-s0:c0.c1023 Target Context unconfined_u:object_r:container_var_run_t:s0 Target Objects rootless-netns-conn.pid [ file ] Source pasta.avx2 Source Path pasta.avx2 Port <Άγνωστο> Host (removed) Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-41.43-1.fc42.noarch Local Policy RPM Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 6.14.9-300.fc42.x86_64 #1 SMP PREEMPT_DYNAMIC Thu May 29 14:27:53 UTC 2025 x86_64 Alert Count 4 First Seen 2025-06-16 20:47:59 EEST Last Seen 2025-06-16 23:14:03 EEST Local ID 2798c030-401f-4098-bfc2-df7600978a8d Raw Audit Messages type=AVC msg=audit(1750104843.891:426): avc: denied { create } for pid=11410 comm="pasta.avx2" name="rootless-netns-conn.pid" scontext=unconfined_u:unconfined_r:pasta_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:container_var_run_t:s0 tclass=file permissive=0 Hash: pasta.avx2,pasta_t,container_var_run_t,file,create Version-Release number of selected component: selinux-policy-targeted-41.43-1.fc42.noarch Additional info: reporter: libreport-2.17.15 reason: SELinux is preventing pasta.avx2 from 'create' accesses on the file rootless-netns-conn.pid. package: selinux-policy-targeted-41.43-1.fc42.noarch component: selinux-policy hashmarkername: setroubleshoot type: libreport kernel: 6.14.9-300.fc42.x86_64 comment: Start rootless containers with podman-compose. component: selinux-policy
Created attachment 2094167 [details] File: description
Created attachment 2094168 [details] File: os_info
This seems to happen with existing containers and recent updates. New containers are not affected. It does not seem to be resolved by applying "ausearch -c 'pasta.avx2' --raw | audit2allow -M my-pastaavx2". The only way that I found that fixes the problem is to run "podman system reset". Of course, this deletes everything from before the recent updates (images, containers, storage, networks, etc.)
Oops, so it must be some relabeling (restorecon <path>) missing around https://passt.top/passt/commit/?id=7aeda16a781848df3dc897da477e6a9bb8a84e67 / https://passt.top/passt/commit/?id=e019323538699967c155c29411545223dadfc0f5, I guess. I'm not sure where rootless-netns-conn.pid is, can you have a look, and 'ls -eZ' it for working and non-working case?
The path is under the runroot `podman info --format "{{.Store.RunRoot}}/networks/rootless-netns/rootless-netns-conn.pid"` shows it Commonly that would be under $XDG_RUNTIME_DIR but in cases where the user did not properly log in it is using a path under /tmp. And the runroot can be fully configured by a user too so realistically it could be anything.
That is correct, in my case the file would be created in /tmp/storage-run-1005/containers/networks/rootless-netns/. After 'podman system reset' and re-runing the containers, the folder no longer exists in my system.
(In reply to Paul Holzinger from comment #5) > The path is under the runroot `podman info --format > "{{.Store.RunRoot}}/networks/rootless-netns/rootless-netns-conn.pid"` shows > it > > [...] > > And the runroot can be fully configured by a user too so realistically it > could be anything. In that case, it would be reasonable to tell users that they have to relabel files themselves, but in this (default) case: (In reply to George Petasis from comment #6) > That is correct, in my case the file would be created in > /tmp/storage-run-1005/containers/networks/rootless-netns/. ...I guess we could add a: restorecon -R /tmp/storage-run-*/* to the post-transaction scriptlet for passt-selinux? Anything against that? George, if you issue that command after installing the new version of passt (and passt-selinux), does the issue go away for existing containers?
I could be missing something but these are tmpfs paths so on the next boot it would be broken again if it doesn't use the right labels by default? Podman knows what file it gives to pasta so should we just relabel it in podman before starting pasta?
(In reply to Paul Holzinger from comment #8) > I could be missing something but these are tmpfs paths so on the next boot > it would be broken again if it doesn't use the right labels by default? This PID file is created by pasta though, isn't it? So if pasta is running as pasta_t, then the label will be correct. I guess the issue just occurs for containers where pasta was running as container_runtime_exec_t. > Podman knows what file it gives to pasta so should we just relabel it in > podman before starting pasta? If it's created by Podman, then yes, I guess we should do that.
(In reply to Stefano Brivio from comment #7) > (In reply to George Petasis from comment #6) > > That is correct, in my case the file would be created in > > /tmp/storage-run-1005/containers/networks/rootless-netns/. > > ...I guess we could add a: > > restorecon -R /tmp/storage-run-*/* > > to the post-transaction scriptlet for passt-selinux? Anything against that? There's no entry for `/tmp/storage-run-%{USERID}` in `pasta.fc`, so just running `restorecon` wouldn't do anything; you'd also need to add the path to `pasta.fc`.
(In reply to Max Chernoff from comment #10) > (In reply to Stefano Brivio from comment #7) > > (In reply to George Petasis from comment #6) > > > That is correct, in my case the file would be created in > > > /tmp/storage-run-1005/containers/networks/rootless-netns/. > > > > ...I guess we could add a: > > > > restorecon -R /tmp/storage-run-*/* > > > > to the post-transaction scriptlet for passt-selinux? Anything against that? > > There's no entry for `/tmp/storage-run-%{USERID}` in `pasta.fc`, so just > running `restorecon` wouldn't do anything; you'd also need to add the path > to `pasta.fc`. Ah, right, that could be: /tmp/storage-run-%{USERID}/containers/networks/rootless-netns/rootless-netns-conn.pid system_u:object_r:pasta_pid_t:s0 but I start wondering if we shouldn't go with: /tmp/storage-run-%{USERID}/containers/networks/rootless-netns system_u:object_r:ifconfig_var_run_t:s0 instead. I mean, is /tmp/storage-run-%{USERID}/containers/networks/rootless-netns an alternate path to /run/user/%{USERID}/containers/networks/rootless-netns? Paul?
It can be any path really so i don't think pasta adding a policy that allows podman paths (which we can change at any given moment) is the correct thing to do. Also keep in mind a relabel will do nothing because these are tmpfs paths that do NOT exist until you start the container. /tmp/storage-run-%{USERID} is the fall back path if XDG_RUNTIME_DIR is not found, but it also used to be /tmp/containers-%{USERID} AFAIK. What I am more confused about is I thought pasta is already allowed to write to /tmp so why does this fail? Looking at the actual policy I see that there are two transition rules already. type_transition container_runtime_t user_tmp_t : dir ifconfig_var_run_t "netns"; type_transition container_runtime_t user_tmp_t : dir ifconfig_var_run_t "rootless-netns"; And looking a directories I create in /tmp they also are user_tmp_t so the transition should happen! So the question is why is the tmp dir not user_tmp_t? When I try to reproduce locally with podmabn by setting custom --root/--runroot arguments to a tmpdir it works just fine. However one thing I noticed there is exactly one test we have failing in CI because of this change as well https://api.cirrus-ci.com/v1/artifact/task/6251328885751808/html/int-podman-fedora-41-rootless-host-boltdb.log.html#t--Podman-kube-play-with-unsafe-hostPath-subpaths--1 And with `make localintegration FOCUS="with unsafe hostPath subpaths"` I am able to reproduce locally so something weird is going in regards to the labels being used which I have to understand first.
Ok so I understand why our CI test fails and that is because it mounts the runroot dir as volume and relabels that via :Z mount option bacially so the files ended up as container_file_t which did not trigger the transition. That is clearly a test issue we should fix in podman. But is still does not explain why in the original AVC container_var_run_t is reported as label owning the files. I don't see any rule that would explain such a label. /tmp/storage-run-%{USERID}/containers/networks/rootless-netns system_u:object_r:ifconfig_var_run_t:s0 could indeed be added to make relabel work but the thing is the "rootless-netns" should not exist when pasta is not running. It is created just before we start pasta so I would always assume we hit the transition rule, I guess the relabel would incorrectly label the files if it is already running but that should not matter? Because once we stop pasta we also delete the rootless-netns dir again.
(In reply to Paul Holzinger from comment #12) > Also keep in mind a relabel will do nothing because these are tmpfs > paths that do NOT exist until you start the container. I think that that's okay in this case though: `/run/user/...` is also on tmpfs, but we still need to run `restorecon /run/user/...` to handle folders that already existed before pasta was upgraded. If that `restorecon` call wasn't there, you'd need to log out and then log back in again before starting any new containers. And this current bug only seems to apply to folders that existed in /tmp/ before pasta was upgraded: > (In reply to George Petasis from comment #3) > > This seems to happen with existing containers and recent updates. New > > containers are not affected. > > It does not seem to be resolved by applying "ausearch -c 'pasta.avx2' --raw > > | audit2allow -M my-pastaavx2". > > > > The only way that I found that fixes the problem is to run "podman system > > reset". > > Of course, this deletes everything from before the recent updates (images, > > containers, storage, networks, etc.) > What I am more confused about is I thought pasta is already allowed to write to /tmp so why does this fail? > > Looking at the actual policy I see that there are two transition rules already. > type_transition container_runtime_t user_tmp_t : dir ifconfig_var_run_t "netns"; > type_transition container_runtime_t user_tmp_t : dir ifconfig_var_run_t "rootless-netns"; That allows pasta to create the folders "netns" and "rootless-netns" with the ifconfig_var_run_t context, and then allow pasta_t ifconfig_var_run_t:file { create open write }; lets pasta write to ifconfig_var_run_t folders, but if the folders "netns" or "rootless-netns" already exist *without* the ifconfig_var_run_t context, then pasta isn't allowed to write any files to them. So this bug (should) only show up if you have running containers, upgrade pasta, and then try to start new containers without rebooting (I think).
(In reply to Max Chernoff from comment #14) > (In reply to Paul Holzinger from comment #12) > > Also keep in mind a relabel will do nothing because these are tmpfs > > paths that do NOT exist until you start the container. > > I think that that's okay in this case though: `/run/user/...` is also on > tmpfs, but we still need to run `restorecon /run/user/...` to handle folders > that already existed before pasta was upgraded. If that `restorecon` call > wasn't there, you'd need to log out and then log back in again before > starting any new containers. And this current bug only seems to apply to > folders that existed in /tmp/ before pasta was upgraded: > > > (In reply to George Petasis from comment #3) > > > This seems to happen with existing containers and recent updates. New > > > containers are not affected. > > > It does not seem to be resolved by applying "ausearch -c 'pasta.avx2' --raw > > > | audit2allow -M my-pastaavx2". > > > > > > The only way that I found that fixes the problem is to run "podman system > > > reset". > > > Of course, this deletes everything from before the recent updates (images, > > > containers, storage, networks, etc.) > > > What I am more confused about is I thought pasta is already allowed to write to /tmp so why does this fail? > > > > Looking at the actual policy I see that there are two transition rules already. > > type_transition container_runtime_t user_tmp_t : dir ifconfig_var_run_t "netns"; > > type_transition container_runtime_t user_tmp_t : dir ifconfig_var_run_t "rootless-netns"; > > That allows pasta to create the folders "netns" and "rootless-netns" with > the ifconfig_var_run_t context, and then > > allow pasta_t ifconfig_var_run_t:file { create open write }; > > lets pasta write to ifconfig_var_run_t folders, but if the folders "netns" > or "rootless-netns" already exist *without* the ifconfig_var_run_t context, > then pasta isn't allowed to write any files to them. So this bug (should) > only show up if you have running containers, upgrade pasta, and then try to > start new containers without rebooting (I think). Ah right for "netns" that could be the problem. However for "rootless-netns" there is exactly one pasta process. If that it is already running then new container just keep reusing it, the process only stops when all containers on custom networks are stopped but in that case we also remove the rootless-netns dir. So on the next container start it would create the dir and trigger the transition rule. So far all user reports (this bz and https://github.com/containers/podman/issues/26473) show the problem on the "rootless-netns" dir only so that confuses me a lot.
This was fixed in the pasta policy here https://archives.passt.top/passt-dev/20250917120450.36181-2-pholzing@redhat.com/ which went into 2025_09_19.623dbf6