Support caller-configured userns with non root uid

[wrr]

Description

I try to integrate gVisor with higher level rootless sandboxing tool. Following the documentation at https://gvisor.dev/docs/user_guide/rootless/ I figured out the best way to integrate is to follow 'Method 2: Caller-Configured Userns': the tool setups the user namespace, and starts runsc to run a sandboxed program within the already configured namespace.

This works only when the uid runsc runs inside the namespace is 0. If the caller process (and thus runsc) runs as a non-zero uid in the user namespace, say 1000, runsc assumes it must set up a user namespace itself, and since there is no namespaces entry in config.json, it fails:

running container: creating container: cannot create gofer process: unable to run a rootless container without userns

For the sandboxing program I try to integrate with gVisor, a design goal is to make sandboxed environment as close to the user normal working environment as possible, so preserving the username (and id) in the sandbox is key.

Technically, inside a user namespace there is little difference between uid 0 and any other uid, it is just cosmetic difference, what matters are the capabilities passed to the process, and user namespace setup can pass any capabilites runsc needs also when not using uid 0.

Why not use Method 3 from the documentation 'True runsc Rootless Mode'? This method doesn't support network isolation. Setting up namespace outside of runsc also allows to work around gVisor's lack of overlayfs support. The caller can just configure any required overlayfs mounts in the user namespace before invoking runsc which doesn't need to know that overlayfs is involved.

If I understand correctly, under 'Method 2' runsc isn't really aware it runs within a user namespace. Perhaps to support running with uid != 0, runsc would need to be explicitly informed that it runs within an already configured namespace, so it skips the userns setup.

Does adding support for this seem feasible and in line with gVisor's goals?

Is this feature related to a specific bug?

No response

Do you have a specific solution in mind?

No response

[ayushr2]

Can't you map the UID 0 inside your userns to the desired non-root UID on the host? Even though the application sees UID 0, when it creates files etc, the UID on the host will be the non-root UID.

Technically, inside a user namespace there is little difference between uid 0 and any other uid, it is just cosmetic difference

Yes, exactly.

what matters are the capabilities passed to the process

The capabilities passed to the process inside the sandbox? You can specify that in the OCI spec I believe while keeping app UID 0.

[wrr]

Can't you map the UID 0 inside your userns to the desired non-root UID on the host? Even though the application sees UID 0, when it creates files etc, the UID on the host will be the non-root UID.

I can do this and this works well with gVisor, but the goal is for the user to keep the username in the sandbox. So the user alice uid 1000, stays alice uid 1000 after activating the sandbox and files accessible to alice are still listed as accessible by alice in the sandbox, not by root. I have this working already on top of Linux usernamespace alone, but would like to add gVisor for added isolation.

[EtiennePerot]

What I've done in the past for another project is to prefix the in-sandbox argv with unshare --map-user, as well as mounting a stripped-down /etc/passwd that only contains the mapped user. But agree it would be nice if gVisor supported this out of the box.

[wrr]

What I've done in the past for another project is to prefix the in-sandbox argv with unshare --map-user, as well as mounting a stripped-down /etc/passwd that only contains the mapped user. But agree it would be nice if gVisor supported this out of the box.

Thanks, this actually does work well. I tried nested namespace before, but only with outer namespace having UID 0 and run into cryptic failures. After more tests what works is to have:

• My namespace setup which maps host UID 1000 (or any other) into userns UID 1000 and starts runsc with UID 1000.
• runsc config which configures another user namespace, which again maps host UID 1000 into userns UID 1000.

The relevant config.json entries are:

   ...
   "linux" : {
      "gidMappings" : [
         {
            "containerID" : 1000,
            "hostID" : 1000,
            "size" : 1
         }
      ],
      "uidMappings" : [
         {
            "containerID" : 1000,
            "hostID" : 1000,
            "size" : 1
         }
      ],
      "namespaces": [
	{
	  "type": "user"
	}
      ]
   },
      "process" : {
       ...
      "user" : {
         "gid" : 1000,
         "uid" : 1000
      }
   },
  ...

Such nested namespace is not ideal, but seems to work well and is sufficient for me. From my perspective this feature request can be closed unless you see some broader gain from supporting this mode without the nested user namespace.