This is a proposal for now, I want to discuss do we want this feature exposed to the native processes at all.
I thought about putting it under e.g. procctl(2), but it seems to not be a natural place.

I believe its immediate use is to allow much easier testing of the namei(9) changes around altroot behavior, in particular for the fixes dteske@ is working on in D58855 and D59990.
On the other hand, it is not obvious if it is useful for something else, but who knows where users end up with.

The changes to pwd_altroot(9) itself could be considered as an independent bug fixes anyway.

Yes, expose it. D59990 can configure the overlay from a native process, dropping the linux_base skip.

pwd_altroot fixes look right on their own (ENOTDIR, no-op when adir is unchanged, error back to linux_pwd_onexec).

Issue: privilege it like chroot. sys_chaltroot has no priv_check. pwd_adir survives native exec (only linux_pwd_onexec_native clears it), so an unprivileged chaltroot then exec of a setuid helper overlays that helper's absolute lookups. Same reason chroot is not free.

Agree that procctl is the wrong home; this belongs next to chroot.

D59990 can stay as-is until this lands. Happy to retarget the tests onto chaltroot after.

In D60035#1377627, @dteske wrote:

Yes, expose it. D59990 can configure the overlay from a native process, dropping the linux_base skip.

I think that the linux tests should go regardless of this proposal. If chaltroot(2) goes in, then more tests can be added that utilize the native interface. But the linux-ABI tests are really independent from this and are useful on its own.

pwd_altroot fixes look right on their own (ENOTDIR, no-op when adir is unchanged, error back to linux_pwd_onexec).

Issue: privilege it like chroot. sys_chaltroot has no priv_check. pwd_adir survives native exec (only linux_pwd_onexec_native clears it), so an unprivileged chaltroot then exec of a setuid helper overlays that helper's absolute lookups. Same reason chroot is not free.

Hmm, I thought that it would be enough to drop altroot for native if setugid binary is executed, but might be you are correct and altroot should be treated same as chroot. In principle it allows the same actions to be taken as chroot, and trying to formulate rules that would prevent that from abusing is too risky.
So I will add the same permission checks as for chroot.

Agree that procctl is the wrong home; this belongs next to chroot.

D59990 can stay as-is until this lands. Happy to retarget the tests onto chaltroot after.

No, please go ahead and commit as is.

In D60035#1377674, @kib wrote:

Extract chroot_unpriv() from kern_chroot.
Use the same privilege checks for chaltroot(2) as for chroot(2).

Privilege check matches. Thanks for adding that.

Issue: pwd_altroot no-op leaks newpwd. Alloc is unconditional; when altroot_vp == oldpwd->pwd_adir the else nullifies oldpwd and the unused newpwd is never dropped.

MAC: kern_chroot still does mac_vnode_check_chroot; sys_chaltroot does not, even when path is not NULL.

In D60035#1377863, @dteske wrote:

In D60035#1377674, @kib wrote:

Extract chroot_unpriv() from kern_chroot.
Use the same privilege checks for chaltroot(2) as for chroot(2).

Privilege check matches. Thanks for adding that.

Issue: pwd_altroot no-op leaks newpwd. Alloc is unconditional; when altroot_vp == oldpwd->pwd_adir the else nullifies oldpwd and the unused newpwd is never dropped.

Fixed, thanks.

MAC: kern_chroot still does mac_vnode_check_chroot; sys_chaltroot does not, even when path is not NULL.

There is no mac callback for chaltroot. I am not sure that we need it, perhaps yes. Also there is no audit event allocated for chaltroot. As well as no man page.
I want to get some more feedback.