-
Notifications
You must be signed in to change notification settings - Fork 70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
install-to-filesystem does not work when targeting LVM #175
Comments
Similar failure using CentOS Stream 9 as the host. $ cat Containerfile.sagano
FROM registry.gitlab.com/centos/cloud/sagano/centos-boot-tier-1:stream9
# Not sur why I can't just use the copr repo, but it doesn't show as an
# enabled repo when I copy it to /etc/yum.repos.d ¯\_(ツ)_/¯
RUN curl -L -o bootc.rpm https://download.copr.fedorainfracloud.org/results/rhcontainerbot/bootc/centos-stream-9-x86_64/06595650-bootc/bootc-202311031759.g634ce23bce-1.el9.x86_64.rpm
RUN rpm-ostree install bootc.rpm
RUN ostree container commit $ image=localhost/sagano-cs9-bootc-copr:latest
$ sudo podman run --rm --privileged --pid=host -v /:/target --security-opt label=type:unconfined_t "${image}" bootc install-to-filesystem --target-no-signature-verification --karg=console=ttyS0,115200n8 --replace=alongside /target
Mounting selinuxfs
ERROR Inspecting filesystem /target: findmnt /target failed: ExitStatus(unix_wait_status(256))
$ sudo ausearch -m avc
----
time->Fri Nov 3 16:07:22 2023
type=PROCTITLE msg=audit(1699042042.505:752): proctitle=2F746D702F2E746D70376174694E4800696E7374616C6C2D746F2D66696C6573797374656D002D2D7461726765742D6E6F2D7369676E61747572652D766572696669636174696F6E002D2D6B6172673D636F6E736F6C653D74747953302C3131353230306E38002D2D7265706C6163653D616C6F6E6773696465002F74617267
type=PATH msg=audit(1699042042.505:752): item=0 name="/lib64/ld-linux-x86-64.so.2" inode=34460089 dev=00:32 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:container_file_t:s0:c264,c980 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(1699042042.505:752): cwd="/"
type=EXECVE msg=audit(1699042042.505:752): argc=6 a0="/tmp/.tmp7atiNH" a1="install-to-filesystem" a2="--target-no-signature-verification" a3="--karg=console=ttyS0,115200n8" a4="--replace=alongside" a5="/target"
type=SYSCALL msg=audit(1699042042.505:752): arch=c000003e syscall=59 success=yes exit=0 a0=55bdd5e15820 a1=55bdd5ddfca0 a2=55bdd5e16ca0 a3=8 items=1 ppid=35181 pid=35183 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4 comm=".tmp7atiNH" exe="/tmp/.tmp7atiNH" subj=system_u:system_r:unconfined_t:s0:c264,c980 key=(null)
type=SELINUX_ERR msg=audit(1699042042.505:752): op=security_bounded_transition seresult=denied oldcontext=system_u:system_r:unconfined_t:s0:c264,c980 newcontext=system_u:system_r:install_t:s0:c264,c980
type=AVC msg=audit(1699042042.505:752): avc: denied { nosuid_transition } for pid=35183 comm="bootc" scontext=system_u:system_r:unconfined_t:s0:c264,c980 tcontext=system_u:system_r:install_t:s0:c264,c980 tclass=process2 permissive=0 |
(this is unrelated to the bug, but what you really want is more like:
This will avoid leaking the RPM (as a file) into the container image and ensure that unnecessary content is properly squashed. |
The failure is totally unrelated to the bootc-in-container (or the OS version of the container), it's about the host SELinux policy. (When you first said "Using c9s" I thought you meant for the host, not the container) |
Right. We've been trying really really really hard to make this work. We have #83 which is related. For #78 I finally just gave up and in that mode did a Can you check that It's really tempting to do that unconditionally but I'm trying to Do It Right as much as possible. I'm not yet sure why it works in some paths but not others. cc @rhatdan |
Oh actually this has nothing to do with selinux...we're already detecting this situation and running The problem is we don't support LVM. One immediate issue seems to be that when executed from a container with a bind mount to the target root, the I think what we need to do here is two things to fix the baseline error:
But that's just preparatory work. I think we'll also need to pick up kargs like |
No filesystem uuid found in target root
when trying install-to-filesystem
using F39 Server
Can't we run the tool that is attempting to install as install_t or unconfined_t? Is this bootc? We could just transition to an unconfined role. Looks like there is a type install_exec_t Which transition to install_t, which is allowed to do anything including put labels that don't exist yet, I believe. |
I amended my comment to indicate I was using a c9s host, even if it is still an LVM issue. |
@cgwalters Hi! I run into the same issue on ARM VM in beaker. ARM VMs in beaker are deployed as LVM when install CentOS Stream 9.
|
@cgwalters Do you think we need to escalate this issue a little bit? Azure RHEL on-demand images are using LVM. And I just tried to do |
Ah, good find. So...I don't think we need to escalate this right now, let's just document the places that it works and the limitation on LVM. The real fix for the "in-place" will be #78 which will default to rewriting the filesystem to not be LVM (i.e. it will default to what the container image specifies). (We still do want to support configuring LVM in this scenario of course, but that gets into its own trickiness) |
Teach `install to-existing-root` how to gather kernel arguments and information we need from `/proc/cmdline` (such as `rd.lvm.lv`). In this case too, we need to adjust the args to use `-v /dev:/dev` because we need the stuff udev generates from the real host root. With these things together, I can do a bootc alongside install targeting a Fedora Server instance. Closes: containers#175 Signed-off-by: Colin Walters <walters@verbum.org>
Teach `install to-existing-root` how to gather kernel arguments and information we need from `/proc/cmdline` (such as `rd.lvm.lv`). In this case too, we need to adjust the args to use `-v /dev:/dev` because we need the stuff udev generates from the real host root. With these things together, I can do a bootc alongside install targeting a Fedora Server instance. Closes: containers#175 Signed-off-by: Colin Walters <walters@verbum.org>
Host system is Fedora 39 Server.
Using the tier1 Fedora ELN image, I created a custom variant that had
bootc
installed from Copr:Built it successfully with
sudo podman build -t sagano-bootc-copr:latest -f Containerfile.sagano .
Tried
install-to-filesystem
:Hmm...looks like it might be SELinux as the culprit:
The text was updated successfully, but these errors were encountered: