Possible to pass devices into a rootless container and allow raw access?

[cyqsimon]

I have a containerised program that requires raw access to /dev/sda. With the following compose.yaml and running rootful, the program can run successfully.

services:
  my-rootful:
    container_name: my-rootful
    image: my-program
    cap_add:
      - SYS_RAWIO
    devices:
      - /dev/sda:rw

I wonder if it's possible to do the same thing, but rootless.

---

I tried to use the same compose.yaml under a non-root user. Of course I'm not expecting it to work and indeed it doesn't. Personally, I suspect that there are two probably sources of error:

1. The non-privileged user does not have CAP_SYS_RAWIO, and therefore cannot create a namespace with it.

So is it possible to assign a particular capability to a user? I tried modifying /usr/lib/systemd/system/[email protected] (or more accurately, using a drop-in file at /etc/systemd/system/user@<UID>.service.d/) to add CAP_SYS_RAWIO (and CAP_DAC_READ_SEARCH just in case) as ambient capabilities, but that didn't work.

2. The UID for host's root gets mapped into something weird in the rootless container, causing some sort of permission issue.

In the rootful container:

# eza -ln /dev/sda
brw-rw---- 8,0 0 11 Nov 09:46 /dev/sda

In the rootless container however:

# eza -ln /dev/sda
brw-rw---- 8,0 65534 11 Nov 09:27 /dev/sda

Not sure why UID 0 on the host would show up as <SUBUID_COUNT> - 2 in the container, but maybe there's a problem here; not sure.

---

Anyways, couldn't get it to work. Any advice is welcomed, thanks.

[nalind]

Unprivileged users normally can't map UID 0 from outside of namespaces they create into their own, so items owned by that user appear as the overflow ID. There's a bit more about this in the "Unmapped user and group IDs" section in user_namespaces(7). Capabilities like CAP_SYS_RAWIO only "work" in the initial namespace, as noted in the "Effect of capabilities within a user namespace" section.

[cyqsimon]

Thanks for the swift response.

---

Unprivileged users normally can't map UID 0 from outside of namespaces they create into their own, so items owned by that user appear as the overflow ID. There's a bit more about this in the "Unmapped user and group IDs" section in user_namespaces(7).

Understood. This makes sense.

---

Capabilities like CAP_SYS_RAWIO only "work" in the initial namespace, as noted in the "Effect of capabilities within a user namespace" section.

I assume this is the part you are referring to?

On the other hand, there are many privileged operations that affect resources that are not associated with any namespace type, for example, changing the system (i.e., calendar) time (governed by CAP_SYS_TIME), loading a kernel module (governed by CAP_SYS_MODULE), and creating a device (governed by CAP_MKNOD). Only a process with privileges in the initial user namespace can perform such operations.

I guess the implicit understanding is that member process of a child namespace can never have privileges in its parent namespace? Am I understanding this correctly?

[nalind]

Right, without help, users in a namespace aren't generally going to be able to do more than the users who are mapped to them could do outside of the namespace. There are certain things that capabilities in the namespace allow UID 0 to do with items owned by other IDs that have also been mapped into the namespace, and that allows us to do quite a bit.