man 2 unshare tells

Use of CLONE_NEWPID requires the CAP_SYS_ADMIN capability

and the suggested read for further information as suggested man 7 pid_namespaces does not really disclose or talk about the prosumable risk that makes it necessary to restrict pid_namespaces to be used by root/CAP_SYS_ADMIN only?

Indeed I wonder strongly what the risk of CLONE_NEWPID would be if run by a non-root user?

In a clone without CLONE_NEWPID the PID namespace would be unchanged and hence much broader and potentially dangerous than it would be the case of a new empty pid namespace.

Sadly the without hackery or user namespaces for a non-root user keeping track of decendent processes in linux cannot be improved when pid namespaces are not available, which though would be a very handy functionality and make it incompehensible to me why only CAP_SYS_ADMIN is thought fit to run CLONE_NEWPID. Did I miss a major point that makes CLONE_NEWPID such a risky busyness?

man 2 unshare tells us

Use of CLONE_NEWPID requires the CAP_SYS_ADMIN capability

and the suggested reading for further information man 7 pid_namespaces does not really discuss the presumable risk that makes it necessary to restrict pid_namespaces to root/CAP_SYS_ADMIN only.

What would the risk of CLONE_NEWPID be if run by a non-root user?

In a clone without CLONE_NEWPID the pid_namespace would be unchanged and hence much broader and potentially more dangerous than it would be int the case of creating a new empty pid_namespace.

Sadly, without some concept of user PID namespaces for a non-root user, keeping track of descendant processes reliably in Linux becomes difficult. pid_namespaces would be very handy functionality and thus it is incomprehensible to me why only CAP_SYS_ADMIN is thought fit to run CLONE_NEWPID. Did I miss a major point that makes CLONE_NEWPID such risky busyness?