I wonder if a chrootat(fd, path) that allows a NULL path would be more general?

Should there be a flags argument?

We do need to spend a capability bit on this?

I'm skeptical of the chroot(8) change. I don't see how it's useful in practice. If committed it should be separate from the syscall addition.

In D41564#950112, @brooks wrote:

I wonder if a chrootat(fd, path) that allows a NULL path would be more general?

Should there be a flags argument?

I'm not sure if I want to semantically mix "make this fd the new root" and "look up this path" bits. As it is now, it mimics fchdir(2). It's also compatible with NetBSD.

We do need to spend a capability bit on this?

Excellent question. I have no idea - my guess would be no, but because there already is CAP_FCHDIR, the purpose of which is also unclear to me, I simply followed suit.

I'm skeptical of the chroot(8) change. I don't see how it's useful in practice. If committed it should be separate from the syscall addition.

Agree - as it is now, it's mostly so that I can test the syscall by hand. Might become more useful in the future.

As for CAP_FCHROOT - I think we should have it, if only for symmetry with CAP_FCHDIR. I don't really want to implement them - the lookup code isn't really suited for tracking rights for root and cwd, and so those two syscalls require full rights to succeed, not just a subset - but we could in the future.

So... how do we proceed with this?

A few more nits to address.