> Well you can[1],

No, you can't, it's an entirely different syscall that does something vaguely similar. IMHO there are a bit too many root-restricted operations that should not have been; but they are, so we're stuck with setuid-enabled "confused deputies" — arguably, it's the root that should be prohibited from calling chroot(2).

> Now: Which database should be used to map a username to a userid? If you're the author of the code in-question, you chose the latter

That's the problem: the choice is implicit. If the author moved setuid/setgid calls way up in the call order, the implicit choice would've also been the safe one but it was literally impossible.

> unshare(CLONE_USERNS|CLONE_FS) can be used

Wait, CLONE_USERNS? That's not a real flag. Did you mean CLONE_NEWUSER?

> Did you mean CLONE_NEWUSER? [~] it's an entirely different syscall that does something vaguely similar

Yes. And I agree, but it also enables chroot(2) to work without being root, which was the syscall we are talking about, and which I still maintain is not as important as reading.

> arguably, it's the root that should be prohibited from calling chroot(2).

> IMHO there are a bit too many root-restricted operations that should not have been

It's a popular opinion. It's also cheap. So what?

> so we're stuck with setuid-enabled "confused deputies"

chroot(8) is not setuid-enabled. This has nothing to do with anything.

> That's the problem: the choice is implicit. If the author moved setuid/setgid calls way up in the call order, the implicit choice would've also been the safe one but it was literally impossible.

False. The setuid/setgid calls are in the right place. The lookup of the database mapping usernames to userids is in the wrong place.

If the rust programmer just read what they wrote they would see this.

If you just read what they wrote you would see this.