Some namespace path joining errors together with user ns about runc HOT 3 OPEN

That particular example is a configuration error -- if you join an existing namespace (such as IPC) and then make a new user namespace you won't have any capabilities over the IPC namespace and so stuff like that will fail and will require changing the configuration.

from runc.

But if I join container test's user ns path instead of create an new user ns, it will work.

                "namespaces": [
                        {
                                "type": "ipc",
                                "path": "/proc/14821/ns/ipc"
                        },
                        {
                                "type": "user",
                                "path": "/proc/14821/ns/user"
                        }
                ],

The container test's user mapping has the same value as this one:

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

from runc.

@lifubang That's just how user namespaces work. Every other namespace instance is owned by a user namespace, and capability permissions are based on the owning user namespace (not the kuid -- there are checks related to the kuid but basic capability checks are not). You can re-create this behaviour using unshare and nsenter:

% unshare -Uri sleep infinity
% nsenter -t $pid -i -- unshare -Urm -- mount -t mqueue mqueue /tmp # fails
% unshare -Urm -- nsenter -t $pid -i # fails due to permission issues

from runc.