but whatever works, it's been three days so whatever gets them green so it unblocks you for bazzite
but whatever works, it's been three days so whatever gets them green so it unblocks you for bazzite
EWe don't have that. These packages get installed via install.sh by invoking rpm-ostree
Jah ok
EIn that case, can I get a supergfxctl project created on Copr? I'll build supergfxctl, the plasmoid, and GNOME shell extension out of that
Jyeah that's probably the best long term plan
EAwesome. Thank you!
J"do the kyle"
ELol
JI'm done with my sabbatical and my job will have me on the road a ton, you don't need my permission to fix anything, Just Do It(tm).
JSomeone was sitting next to me and saw my framework with bluefin and was like "what is that?!?!?!"
A
EI really want to get a 16
Jyeah then I fired up a cluster and everyone was like "what?!"
Jme too, i just can't justify it right now
BI wonder if I need to do the podman-system-generator dance?
Bthis issue mentions it
BGitHub
Issue Description I copypasted .container file from podmansh man page but the way I did it, it added some trailing whitespaces and lines containing only whitespaces: [Unit] Description=The podmansh...
AThis is setting the last component of the selinux label which corresponds to the "level" - this is technically only relevant on systems with multi-level security
AFor nested containers you're supposed to be able to do
label=nested - I am not sure why they're manually setting the context to container_t
AYou also need a recent podman version for this to work. I'm currently semi-engaged with upstream troubleshooting some selinux issues in ublue
AThe main issue is that podman mounts the rootfs layer with a
context= flag and this causes the selinux operations to fail because the selinux context is hardcoded by podman and can't be modified in the overlayfs layerAlabel=nested changes this behavior so that the overlayfs will be mounted with
rootcontext= instead which only sets the selinux context of the rootfs inodeAbut on top of this you still need:
-v /etc/selinux:/etc/selinux
--privileged
--security-opt=unmask=/sys/fs/selinux
-v /etc/selinux:/etc/selinux
--privileged
--security-opt=unmask=/sys/fs/selinux
ABecause afaict label=nested doesn't mount the necessary files for libselinux to work
Amm maybe run with
Also if you want "real root" then label=disable should work
--privileged if you want thisAlso if you want "real root" then label=disable should work
Abut selinux relabeling will only work in bind mounts
Anot inside the container rootfs because of the
context= stuff aboveBi'm going to try with a completely different image and see what differences there are
AI got pointed to this discussion by cgwalters earlier today: https://github.com/containers/storage/pull/1608
As it stands podman OCI selinux handling is kind of flaky
As it stands podman OCI selinux handling is kind of flaky
GitHub
Fixes: containers/podman#18543
AThe root cause is that selinux is not namespaced so semantically containers and selinux will not really play along that well
BI got pretty far with this this quadlet:
BBbiggest showstopper right now is that I can't use sudo for anything. it prompts for password, never accepts the password, so I can't investigate the container
Bthe whole thing is fascinating, there's a lot of moving parts here
Ayou can use podman exec -u 0 to investigate
AMm this is not a rootful container is it?
Bno, I don't think so
AIs it trying to read /etc off the host or the container? (Sorry not familiar with podman sh)
BI think it's trying to read /etc from the container, I suspect it's not mounted but should be
Bat least /etc/shadow should be?
Jno one's familiar with podmansh, it just landed. We might be the first outside of the podman team playing with it
Bgoing where noone has gone before
Bit's my mantra lol
ACan you do:
Inside the container
id -Z and ls -lZ /etc/sudoers /etc/shadowInside the container
AYeah I was looking for docs
ANada lol
AI got to the PR it got merged on trying to see
AMm so we are trying to make sudo work so we can replace the system shell?
Amm maybe also wc -l /etc/shadow inside and out side of the container too
AIt doesn't seem like it automounts etc or anything like that
ASo probably what is happening is that your /etc/shadow and other related files don't have the user
