Podman Permissions on Kicksecure

Mon, 09 Mar 2026 00:00:00 +0000

This article is part of my Self-Hosting with Kicksecure series.

1. Introduction

When I first tried running rootless Podman on Kicksecure, containers wouldn’t start. The errors looked like:

Error: command required for rootless mode with multiple IDs: exec: "newuidmap": executable file not found in $PATH

Or:

zsh: permission denied: /usr/bin/newuidmap

Rootless Podman requires newuidmap and newgidmap to map a single user ID to the thousands of IDs needed inside containers. The issue? Kicksecure restricts access to these binaries by default as a security measure. This article documents how I solved this properly.

2. Understanding the Problem

I checked Kicksecure’s configuration:

dpkg-statoverride --list /usr/bin/newuidmap

Output:

root root 744 /usr/bin/newuidmap

Only root can execute these binaries. For most systems, this is good security. But rootless containers need access.

3. First Attempt: dpkg-statoverride

My first approach was to use dpkg-statoverride to change permissions:

addgroup podman-users
usermod -aG podman-users user
dpkg-statoverride --remove /usr/bin/newuidmap
dpkg-statoverride --remove /usr/bin/newgidmap
dpkg-statoverride --update --add root podman-users 4750 /usr/bin/newuidmap
dpkg-statoverride --update --add root podman-users 4750 /usr/bin/newgidmap

This worked temporarily. But then I ran an apt upgrade, and permission-hardener reverted my changes. My containers broke after the next update.

4. The Correct Solution

Kicksecure provides a proper way to whitelist binaries through permission-hardener.

4.1. Create Whitelist Configuration

mkdir /etc/permission-hardener.d

Created /etc/permission-hardener.d/50_podman.conf:

/usr/bin/newuidmap exactwhitelist
/usr/bin/newgidmap exactwhitelist

The exactwhitelist directive tells permission-hardener to leave these binaries alone while still applying restrictions to everything else.

4.2. Apply Changes

permission-hardener enable all

Verified the permissions changed:

ls -l /usr/bin/newuidmap

-rwsr-x--- 1 root podman-users 14976 Jan 10 12:00 /usr/bin/newuidmap

5. Configuring Podman

Even with correct permissions, Podman couldn’t find these binaries in its path. I created a containers configuration file.

As the user account, created ~/.config/containers/containers.conf:

[engine]
newuidmap_path = "/usr/bin/newuidmap"
newgidmap_path = "/usr/bin/newgidmap"

6. Verifying User ID Mappings

I confirmed my user had the necessary ID mappings:

grep $(whoami) /etc/subuid
grep $(whoami) /etc/subgid

Output:

user:100000:65536

This means user can map UIDs 100000-165535 inside containers.

7. Testing

Switched to the container user and tested:

su - user
podman system migrate

This succeeded without errors. Then I ran a test container:

podman run --rm hello-world

8. Why This Matters

Rootless containers are a significant security improvement:

Container escapes are contained to the user account
Kernel exploits have limited impact
File ownership is handled via ID mapping, not root privileges

Kicksecure’s default restrictions are correct for most use cases. Podman is an exception that requires explicit whitelisting.

9. Troubleshooting

Permission Denied

Check group membership:

groups user

Ensure podman-users appears in the list. A logout/login might be needed.

Path Not Found

Ensure the containers.conf file exists:

ls -la ~/.config/containers/containers.conf

Changes Reverted After Update

Verify the whitelist file:

cat /etc/permission-hardener.d/50_podman.conf

Then re-run:

permission-hardener enable all

10. Tracking the Change

This is exactly the kind of configuration change worth tracking:

cd /etc
git add .
etckeeper commit "Whitelisted newuidmap/newgidmap for rootless podman"

More on this in my Etckeeper on Kicksecure article.

10. What’s Next

Podman Quadlets on Kicksecure

Permissions on Matty Spangler