'sethostname' syscall not working without --cap-add=SYS_ADMIN in rootless Podman container

[mohaa7]

When running a rootless Podman container (in my case with crun as the runtime), the sethostname syscall fails unless the --cap-add=SYS_ADMIN flag is provided. This is problematic as SYS_ADMIN is a very broad capability and granting it introduces unnecessary security risks for operations that only require modifying the hostname.

Steps to Reproduce:

• Start a rootless container using podman and crun: podman --runtime=crun run --rm <image> bash -c "hostname new-hostname"
• Observe the failure of the sethostname syscall.
• Retry the same command with --cap-add=SYS_ADMIN, which works but adds excessive privileges.

Expected Behavior:

The sethostname syscall should succeed without requiring the SYS_ADMIN capability, as the operation can be scoped to the container namespace and does not inherently require such elevated privileges.
Observed Behavior:

The syscall fails unless --cap-add=SYS_ADMIN is explicitly added.

Notes:

• Using --cap-add=SYS_ADMIN is not a feasible workaround in many scenarios due to the security implications.
• A minimal capability like CAP_SET_HOSTNAME (if supported) or an alternative solution to isolate the sethostname syscall behavior for rootless containers would be preferable.
• This issue affects applications or scripts running within containers that need to set a custom hostname, such as testing environments or application configurations relying on hostname customization.

Environment:

    Podman Version: 4.9.4-rhel
    Runtime: crun
    OS: Rockylinux
    Kernel Version: 4.18.0-553.34.1.el8_10.x86_64
    Rootless Mode: Yes

[sbrivio-rh]

A minimal capability like CAP_SET_HOSTNAME (if supported) or an alternative solution to isolate the sethostname syscall behavior for rootless containers would be preferable.

This is not a matter for Podman, that would be a matter for the Linux kernel. But I doubt that a capability like that would be acceptable, because it doesn't sound like a very common use case.

Did you consider using UTS namespaces? See uts_namespaces(7). You could detach your own hostname namespace and set the hostname there, at least for applications or scripts that need their own hostname.

[mohaa7]

You mean using the --uts=private option can isolate the hostname setting within the container’s UTS namespace? Didn't worked in my case!

[sbrivio-rh]

I meant UTS namespaces. I don't know what that Podman option does and how you're using it, I'm just suggesting you read up about them because they might address your needs.

[nalind]

Even in a new UTS namespace (which is created by default, per podman-run(1)), the kernel requires that the process calling sethostname(2) have CAP_SYS_ADMIN in the user namespace which owns that UTS namespace.

The good news is that as a rootless user, you're already creating a user namespace that you own in which to run the container, and even with CAP_SYS_ADMIN in that user namespace, the container doesn't have privileges over UTS namespaces outside of it. The UTS namespaces documentation @sbrivio-rh pointed to, along with namespaces(7), explain things better than I can here.

I've found lsns -T to be helpful for visualizing things, when run from outside of the running container while it's still running.