@mjg59 I think it would be a bad idea in long term.
It's pretty common to join together pieces of paths from different sources. This case and the symlink case are more-or-less-legitimate situations when a program that would wish to set that prctl might need to deal with dotdot.
Given that we're talking about per-process setting, libraries would need to be able to deal with living in a process that has the prctl enabled. Many libraries don't have knowledge about provenance of paths they manipulate, so the most expedient way of ensuring they work is to do dotdot resolution themselves.
This makes bugs where dotdot resolution can be controlled by the user harder to detect, as the path is not passed to a syscall. It also causes libraries to wish to perform symlink resolution "manually", which works around protected_symlinks sysctl.
I wonder if adding a flag to openat which prohibits dotdot in the path argument itself would be helpful. It's probably way harder to plumb and obviously provides no way to deal with preexisting code, but provides a way to be careful that's much cheaper in terms of amount of coding/thinking/additional dependencies than what's available now.
