Mounting a group-writable folder into a systemd controlled quadlet for an unprivileged user

[funkyfuture]

i'm having difficulties to set up a container with a mounted volume, my eventual goal is to run a service that:

• runs inside a systemd controlled container
• is executed by an unprivileged user
• can write to a mounted host directory that belongs to the staff group and has the sticky bit for groups set
• for context: these files are processed by a privileged user of the host system; login users that are member s of the staff group can place files in that directory

to achieve that i define a GIDMap setting in the .container unit that is restricted to a group mapping only, see the test script below.

crun will throw an error message that is rather misleading:

Error: OCI runtime error: crun: write to /proc/sys/net/ipv4/ping_group_range (are all the IDs mapped in the user namespace?): Invalid argument

so, i'd appreciate hints in these regards:

1. what is actually causing the error, what am i missing with my attempt?
2. should i report this to the crun maintainers?

---

#!/bin/sh

set -ex

CONTAINER_FILE=/root/Containerfile
QUEUE_FOLDER=/var/lib/queue
SERVICE_NAME=queue-folder-test
STAFF_GID=$(getent group staff | cut -d ':' -f 3)

mkdir -p $QUEUE_FOLDER
chown root:staff $QUEUE_FOLDER
chmod u=rwx,g=rwxs,o= $QUEUE_FOLDER

cat > $CONTAINER_FILE << EOF
FROM alpine
RUN addgroup -g 1000 container-staff \
 && adduser -G container-staff -D -H container-user
USER container-user
CMD ["/bin/sh", "-c", "touch", "/container-queue/test"]
EOF

podman build --tag "$SERVICE_NAME" --file $CONTAINER_FILE .

cat > /etc/containers/systemd/$SERVICE_NAME.container << EOF
[Container]
ContainerName=$SERVICE_NAME
Image=$SERVICE_NAME

GIDMap=g1000:$STAFF_GID

Volume=$QUEUE_FOLDER:/container-queue:z

[Install]
WantedBy=default.target
EOF

systemctl daemon-reload
systemctl enable $SERVICE_NAME
systemctl start $SERVICE_NAME

[jmrplens]

Your mapping never maps GID 0, and that is what the container dies on. With podman 5.4.2 the same mapping gets rejected before crun is involved, with a message that names the problem:

$ podman run --rm --gidmap g1000:50 alpine echo ok
Error: container uses ID mappings ([]specs.LinuxIDMapping{specs.LinuxIDMapping{ContainerID:0x3e8, HostID:0x32, Size:0x1}}), but doesn't map GID 0

The write to ping_group_range is the same problem further down. podman sets that sysctl inside the container's namespace, the write is rejected because the ids involved are not mapped, and crun can only report the write that failed. So I would not file anything against crun. The message quoted above comes from podman itself, so if you still see the crun wording on a current podman, podman is the place to raise it.

The g prefix is why the mapping ends up that thin. From podman-run(1), section "Passing only one of --uidmap or --gidmap": if only one of the two is given, podman assumes the mapping refers to both UIDs and GIDs and applies it to both, and the u and g flags exist to say that this one should not be copied over. So GIDMap=g1000:$STAFF_GID leaves you with exactly one GID entry, no UID map at all, and no GID 0.

The bigger thing is that you do not need the namespace here. Your unit is in /etc/containers/systemd, so it is a rootful quadlet, and in a rootful container the GIDs are already the host GIDs. Running the process as an unprivileged user that is in the staff group is enough:

[Container]
User=1000
Group=50
Volume=/var/lib/queue:/container-queue:z

50 being whatever getent group staff gives you. They are two separate keys in the unit.

I set a directory up the way your script does, root:staff with u=rwx,g=rwxs,o=, and the file comes out owned by 1000:50. Dropping the Group= line is what breaks it, with touch: /container-queue/b: Permission denied, since uid 1000 has no other way into a directory that only staff can write to.

If you want the namespace anyway, it has to map 0 as well. This works on the same directory:

GIDMap=0:0:1
GIDMap=1000:50:1
UIDMap=0:0:1
UIDMap=1000:1000:1
User=1000
Group=1000

One thing that is waiting for you once the mapping is sorted: CMD ["/bin/sh", "-c", "touch", "/container-queue/test"] does not create the file. With sh -c the argument after the command string becomes $0, so touch runs with no operands, prints its usage and exits 1. Either CMD ["/bin/sh", "-c", "touch /container-queue/test"] or CMD ["touch", "/container-queue/test"].

And if this unit is ever meant to run under a user's own systemd instance rather than root's, that is a rootless quadlet, the namespace is back, and the host directory then has to be reachable through that user's subuid range instead of through group membership.

[funkyfuture]

thank you very much! your elaboration really helped me a lot to get my grip around this.