About Cap.

Some root managers or specific versions of managers differ in handling the cap of the container attach.

For example, KernelSU (11682) is executed on the host:

tdgsi_arm64_ab ~ # grep -E '^Cap(Eff|Prm|Bnd)' /proc/self/status
CapPrm: ffffffffffffffff
CapEff: ffffffffffffffff
CapBnd: ffffffffffffffff

When attaching:

tdgsi_arm64_ab ~ # lxc-attach ubuntu --clear-env -- grep -E '^Cap(Eff|Prm|Bnd)' /proc/self/status
CapPrm: ffffffffffffffff
CapEff: ffffffffffffffff
CapBnd: fffffffcfdfcffff

It can be seen that the cap boundary set of the container process under attach is correctly set, while the Effective Capabilities Set and Permitted Capabilities Set are inherited from the host, and the actual cap of the container is not restricted.
At present, the effective solution is to add lxc.no_new_privs=1 in the container config file or global config file to prevent the container from obtaining new privilege capabilities.
Then the ability of attach will be normal:

tdgsi_arm64_ab ~ # lxc-attach ubuntu --clear-env -- grep -E '^Cap(Eff|Prm|Bnd)' /proc/self/status
CapPrm:	0000007cfdfcffff
CapEff:	0000007cfdfcffff
CapBnd:	0000007cfdfcffff

Considering that this is a specific issue, is it necessary to enable lxc.no_new_privs on Android by default?