Categories
Software

Journeys with (not) Podman – Part 2

Perfect is the Enemy of Done

In the previous post, I was attempting to get all of the services that I wanted to run on my local server working within rootless Podman containers and using their own host user accounts.

I kept circling around the same issues and was not moving forward with actually getting anything working. I believe that I may have been more successful if I had more than a rudimentary understanding of SELinux.

In a last-ditch attempt, I time boxed another session to see if I could achieve some success. However, I once again failed to make progress. It was at this point that I reminded myself of my ultimate goal, I wanted self-hosted services to help improve my personal organisation and life. Using Podman was a secondary goal and had become a hindrance in achieving my primary objective so, I decided to shelve playing around with Podman in favour of Docker.

Yes, Podman arguably has a better security posture than Docker and Podman is more open-source friendly but, this server will not be exposed to the larger internet. Also, I do not see the benefit in halting progress in the pursuit of perfection.

Since I already have experience with rootless Docker, it was relatively easy to get everything running as needed. Yay! Now time to move on with life.

I am sure I will revisit Podman in the future so, if you have any hints or tips, feel free to leave a comment on either of these two posts.

In the meantime, I will continue to enjoy my self-hosted services and the productivity boosts that they provide.

Categories
Software

Journeys with Podman – Part 1

These are my no-nonsense blow-for-blow notes of what I have done to get Podman working. They contain very little editing as they are aimed at helping me to remember the process I went through in case I need to do it again in the future and to hopefully help anyone else who may have experienced the same issues.

It is not really a tutorial, more a record of the steps that I tried.

Attempting to run rootless Podman on Fedora Linux 43 (Server Edition) as an alternative to Docker.

My filesystem is split so /home, /var and /var/log are on their own partitions.

To try to maintain security best practices, I have decided to give each service I run their own users on the host that can run that specific container.

Test containers:

  • nginx (under it’s own user without root access)
  • wger (under it’s own user without root access)

Also have an administrator user that does have sudo privileges.

wger is the first service that I’d like to run but the documentation for that project suggests running it behind nginx as its reverse proxy. So, I am starting with nginx

After following instructions for setting up rootless Podman, I tried to run nginx container by su nginx from the administrator user but it would not work. After searching online, I realised that I must be actually logged in as the user not use su.

Once logged in, tried to run the nginx container:

podman run --name nginx-base -p 8080:80 nginx:latest

but was greeted with:

/bin/sh: error while loading shared libraries: /lib/x86_64-linux-gnu/libc.so.6: cannot apply additional memory protection after relocation: Permission denied

Created Podman config in user space:

touch ~/.config/containers/storage.conf

Added the following content:

[storage]
driver = "overlay"
runroot = "/run/user/1003"    
graphroot = "~/.local/share/containers/storage"

Where 1003 is the id of the nginx user.

It did not work. Checked graphRoot:

podman info | grep graphRoot

Showed:

graphRoot: /home/nginx/~/.local/share/containers/storage

ChatGPT got me to check for noexec on the /home partition:

mount | grep home

But output was:

/dev/mapper/fedora-home on /home type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota)

so no issue there. It also got me the check for missing subordinate UID/GID ranges:

getenforce
grep nginx /etc/subuid
grep nginx /etc/subgid

But that was fine too:

Enforcing
nginx:720896:65536
nginx:720896:65536

ChatGPT also mentioned the system may enforce SELinux and is denying executable memory inside the rootless user namespace. So to check for denials:

sudo ausearch -m avc -c runc

Output:

<no matches>

And run:

sudo journalctl -t setroubleshoot -o cat

Truncated output showed many entries like so:

SELinux is preventing docker-entrypoi from read access on the file /usr/lib/x86_64-linux-gnu/libc.so.6. For complete SELinux messages run: sealert -l <SOME-UUID>

So, ran:

sealert -l <SOME-UUID>

Where <SOME-UUID> was replaced with one of the many ones that were shown. Output showed lots of information including something about running restorecon -v on the libc.so.6 file.

NEXT STEPS: Figure out why invalid path is given for graphRoot and looking into restorecon (and here). I know nothing about SELinux so will have to do some more learning in that space.

(Irrelevant at this stage) Copied config out of container:

podman cp nginx-base:/etc/nginx/conf.d/default.conf ~/nginx/default.conf

Random useful links:

Part Two: