userns mappings and reusing existing userns from a specified path

[alban]

trafficstars

When the config reuses an existing userns:

    "namespaces": [
        {
            "type": "user",
            "path": "/proc/1234/ns/user"
        },

It is unclear how mappings should be specified:

    "uidMappings": [
        {
            "containerID": 0,
            "hostID": 1000,
            "size": 32000
        }
    ],

If the existing userns already has mappings configured, the runtime will not be able to write to /proc/$$/uid_map again (see man 7 user_namespaces).

Questions for the runtimes:

• Should the runtime ignore any uidMappings or gidMappings sections when a path is specified for userns?
• Or should it check that the current mappings are already configured exactly as specified in config.json?
• Or should it return an error when it fails to configure the mappings again?
• Should runtimes support using existing userns with unconfigured mappings? (That does not seem useful to me because how would several containers share the same userns? That seems racy.)

Questions for the users:

• Should users avoid specifying the uidMappings or gidMappings sections?
• Or should they specify the mappings and ensure the specified path refers to a userns with the same mappings?

Note that runtimes might need to know the mappings for mounting some tmpfs with options like ,uid=1000,gid=1000.

[wking]

• Or should it return an error when it fails to configure the mappings again?

This is my preference.

I agree that the unmapped case doesn't seem very useful, but don't think it's worth adding spec language to forbid it.

Note that runtimes might need to know the mappings for mounting some tmpfs with options like ,uid=1000,gid=1000.

Do you need to know the mapping for this? Don't you just need to know what IDs are mapped inside the container? Either way, if you're joining an existing user namespace, you can always look this up ahead of time before writing your config.

[alban]

Or should it return an error when it fails to configure the mappings again? This is my preference.

Ok. Should it be a "MUST"?

I agree that the unmapped case doesn't seem very useful, but don't think it's worth adding spec language to forbid it.

Fair enough.

Note that runtimes might need to know the mappings for mounting some tmpfs with options like ,uid=1000,gid=1000.

Do you need to know the mapping for this? Don't you just need to know what IDs are mapped inside the container?

I am not sure, I just noticed those options in /proc/self/mountinfo inside the container. But maybe it is displayed by the kernel in mountinfo but does not need to be given at the mount() syscall: I don't see it in runc.

Either way, if you're joining an existing user namespace, you can always look this up ahead of time before writing your config.

Ok.

[wking]

Or should it return an error when it fails to configure the mappings again?

This is my preference.

Ok. Should it be a "MUST"?

It's already covered by this MUST.

Note that runtimes might need to know the mappings for mounting some tmpfs with options like ,uid=1000,gid=1000.

Do you need to know the mapping for this? Don't you just need to know what IDs are mapped inside the container?

I am not sure, I just noticed those options in /proc/self/mountinfo inside the container. But maybe it is displayed by the kernel in mountinfo but does not need to be given at the mount() syscall: I don't see it in runc.

It would get to runc via a caller-specified options entry like here. And yeah, they're optional.