Arestorecon fails due to
lsetxattr() call failing
AI do think so
AI’m not sure why lsetxattr is failing when my container is running as rootful and —privileged
GGitHub
Issue Description In CI, with updated Rawhide, and Fedora images (c20230706t200047z-f38f37d13 at time of opening issue), the entire matrix fails on three tests with the same/similar error: Failed t...
GNvm
GDoesn't seem to be the right issue
AYeah looks like they actually get unlabeled_t there when they shouldn’t
Athe weird thing is that if I do like
touch test then that file is unlabeled_tABut the files installed via rpm get container_file_t
GWhar
Show initate a release-please action manually?
Slike for testing purposes?
AI confirm that by creating a new file with
touchABut then doing dnf install -y greetd still gives me files with
container_file_tGHuh
GIs there already an issue reported in this?
AI don’t think so
GProbably should make one then
GAs a side note: when installing sddm, it doesn't add the user
GSo post install you need to manually add the sddm user
AYeah I see that with some packages
AI also stared to think about how selinux interacts with containers
Grpm-ostree or podman? I'm thinking rpm-ostree but idk
AJust plain dnf install on a fedora container shows the errors
AThe bugs are probably in the packaging
GAh
Brpm-ostree is essentially just downloading packages then using rpm to install them on a seperate root filesystem (with help of --root argument)(its a bit more complex but thats the gist of it)
Bok then it creates a ostree thing from it and sets it as a what to be booted to on next boot
AI guess the first thing to fix is to get
lsetxattr() working inside a rootful containerAI don’t see any reasons why it doesn’t work
Ahttps://github.com/containers/common/blob/main/pkg/seccomp/seccomp.json#L244C6-L244C6
afaict it should be allowed
afaict it should be allowed
Bis that in any way connected to selinux cause selinux is one of rare mysteries to me in linux
Aselinux file labels are just extended filesystem attributes
AThis setfattr command is equivalent to
chconAin theory we should able to relabel a file manually by calling setfattr
AThis is failing inside a container
Bpossibly a limitation of overlayFS
Bcould that be it
KNoticed this recently, can't setcap either
GIt fails in a normal container too
GIn a fedora container I mean
AMm maybe but then it should work on bind mounts no?
ASome research suggest overlayfs supports selinux
AG@akdev did you report the podman restorecon issue?
ANo, but I did identify why I was getting container_t - turns out that rootful podman sets the filesystem label for the underlying overlayfs
AI’m not really sure what issue to file tbh, restorecon works on bind mounts
ASo it is related to overlayfs somehow
AMm I found:
label=nested: Allows SELinux modifications within the container. Containers are allowed to modify SELinux labels on files and processes, as long as SELinux policy allows. Without nested, containers view SELinux as disabled, even when it is enabled on the host. Containers are prevented from setting any labels.
