[stormbrew]

The problem is that the setuid program does have the same view of the namespace as its caller. When you run a setuid binary it inherits all aspects of the process that exec()'d it, including its namespaces.

Ok, so let's make this more concrete. The scenario we're discussing is a user who wishes to (illegitimately) elevate their privileges, and has the ability to mount, and in particular bind/union mount:

    > mkdir ~/my-etc
    > echo 'badperson   ALL=NOPASSWD:(ALL:ALL) ALL' > ~/my-etc/sudoers
    > mount --bind ~/my-etc /etc # note: you could also insert a command to bump us into a new filesystem namespace before this if you want, or assume that say logind did it for us, it wouldn't change anything about what happens next
    > sudo -s
    # rm -rf /*

This happens because sudo is a setuid program, and it inherits the filesystem namespace of the shell that ran it. In that namespace, the real sudoers file has been masked with a fake one that says badperson can sudo to any user they want, and so it lets them.

That this is the mechanism of privilege escalation that linux uses is fundamental to why mounting (and bind mounting) is a privileged operation. Plan9 does not have either root, nor setuid programs, nor filesystem-stored capabilities, and so does not suffer from this and you can manipulate your namespace to your heart's content.

> Plan9 has no better way than that, no way to make /bin rebinding work in a way that makes sense for privilege escalation.

Please just read some things about plan9 already.