jail: allow root to implicitly widen its cpuset to attach


jail: allow root to implicitly widen its cpuset to attach

The default behavior for attaching processes to jails is that the jail's
cpuset augments the attaching processes, so that it cannot be used to
escalate a user's ability to take advantage of more CPUs than the
administrator wanted them to.

This is problematic when root needs to manage jails that have disjoint
sets with whatever process is attaching, as this would otherwise result
in a deadlock. Therefore, if we did not have an appropriate common
subset of cpus/domains for our new policy, we now allow the process to
simply take on the jail set *if* it has the privilege to widen its mask

With the new logic, root can still usefully cpuset a process that
attaches to a jail with the desire of maintaining the set it was given
pre-attachment while still retaining the ability to manage child jails
without jumping through hoops.

A test has been added to demonstrate the issue; cpuset of a process
down to just the first CPU and attempting to attach to a jail without
access to any of the same CPUs previously resulted in EDEADLK and now
results in taking on the jail's mask for privileged users.

PR: 253724
Approved by: re (gjb)

(cherry picked from commit 60c4ec806dfd0f79edf8ca3abc04bbb69c0418f7)
(cherry picked from commit c4ccb6d1be1f00ebcda9e83f06db55f9d6c152ac)


kevansAuthored on Feb 26 2021, 9:46 PM
R10:661e2b8e1486: ddb: fix show devmap output on 32-bit arm