no one's familiar with podmansh, it just landed. We might be the first outside of the podman team pl
no 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
AYou could try the following to confirm:
podman exec -it -u 0:0 into the container and then do passwd $youruserincontainerAIf this works and you can set a password then maybe sudo will work
B$ id -Z
unconfined_u:unconfined_r:spc_t:s0Athis is good
B$ ls -lZ /etc/sudoers /etc/shadow
-rw-r-----. 1 root shadow system_u:object_r:container_file_t:s0:c1022,c1023 729 Jul 31 01:17 /etc/shadow
-r--r-----. 1 root root system_u:object_r:container_file_t:s0:c1022,c1023 1671 Aug 3 2022 /etc/sudoersAselinux should not be a problem according to this,
spc_t is a highly privileged domain so it should be able to read/write to container_file_t files
spc_t is a highly privileged domain so it should be able to read/write to container_file_t files
JGitHub
Podman: A tool for managing OCI containers and pods. - containers/podman
Jthis is the only doc we have afaict
Bi am not sure how I can do a
podman exec since it's a rootless container running as the fullu user, who has podmansh set as the shell. so I don't know how to do any podman things in the context of that userBoh interesting
BI passed in /etc/passwd /etc/sudoers /etc/shadow as volumes and now the uid mapping is getting in the way
B$ ls -la /etc/passwd
-rw-r--r--. 1 root root 1417 Aug 3 17:00 /etc/passwd
$ sudo su
sudo: /etc/sudoers is owned by uid 65534, should be 0
sudo: no valid sudoers sources found, quitting
sudo: error initializing audit plugin sudoers_audit
Ayou can just do podman exec from the user I guess mm
AIf the user has no shell then probably
sudo -u $user podman may still work?AYou don't want these ones inside the container because your user can't read them anyway (well /etc/shadow can't be read)
AIf you get sudo working inside the container then we can probably use
nsenter -t 1 to get real root
Bthis worked with some caveats. had to start as root, cd to the user's home, then run it and it worked!
ATry changing the password inside the container with passwd (don't pass /etc/shadow and /etc/passwd through though)
BBhowever ... !
Bpodman exec -it -u 0:0 into the container and then do passwd $youruserincontainer <- that workedJ@EyeCantCU nice work getting the builds working! thanks!
BJthis one is above my skill level if someone wants to take a look: https://github.com/ublue-os/nvidia/pull/140
GitHub
This makes it possible to run it on arm64 macOS.
JI like the idea of building stuff on fcos so that we can just use the stable channel, the less numbers to keep track of the better, heh.
ENo problem. Glad the ball is rolling again. Want to add the GNOME extension but for whatever reason every time I tried building it COPR failed to remove the chroot environment. Given the same extension compiled just fine for Bazzite yesterday, I'd imagine it's a COPR bug and I'll just try later today or tomorrow
Band success @akdev - I got sudo access by using the podman exec -u 0:0 to add my container user to the sudo group
Bnow it's down to selinux issues.
Aselinux should actually be ok, what issues do you have now?
BBafter gaining sudo in the container I did an apt update & apt upgrade
Bsuccess!
Bi removed
--privileged and removed the /etc/selinux mount
B@bketelsen do you know if you can run commands during the pre/post startup of theis container maybe most of distrobox stuff could be implemented to this
Bsince distrobox uses multiple approches to get stuff in some of them are doing mount commands and such
Bi studied the distrobox inits - they are a work of art.
Bthere seem to be two options for running commands. There's
RunInit=true which would execute /sbin/init, and there's the Exec= which runs sleep just to get the container goingByea and cold start is also one
Bcold start on these hurts because there's no system cache of containers for rootless podman, so the container will be pulled the first time no matter what
Bthe edge doesn't bleed any harder than this - we're there
