I think it's a precaution. Unprivileged users are not allowed to apply confinements to programs like sudo which are set-user-id (or have file capabilities set), in case it confuses them into performing actions they did not intend to allow.

In some cases this is enforced by preventing elevation by set-uid etc. This is the approach taken when filtering system calls with seccomp.

However for namespaces, the intention was very much to allow namespacing user ids. So I suspect there was no interest in adding the special case, to enforce no-new-privs when entering a PID namespace, when you do not already have full privilege.

I think it's a precaution. Unprivileged users are not allowed to apply confinements to programs like sudo which are set-user-id (or have file capabilities set), in case it confuses them into performing actions they did not intend to allow.

In some cases this is enforced by preventing elevation by set-uid etc. This is the approach taken when filtering system calls with seccomp.

However for namespaces, the intention was very much to allow namespacing user ids. Namespaces were merged into mainline Linux in an incremental process, starting with the simplest, and culminating in user namespaces. I suspect there was little interest in adding the special case, to enforce no-new-privs when entering a PID namespace, when you do not already have full privilege.

The interaction of these namespaces becomes quite intricate, so it's nice not to proliferate too many different cases, if those cases are not in very high demand.