Podman Permissions on Kicksecure
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.