New AT_ flags for restricting pathname lookup [LWN.net]

New AT_ flags for restricting pathname lookup

Posted Oct 7, 2018 0:34 UTC (Sun) by judas_iscariote (guest, #47386)
Parent article: New AT_ flags for restricting pathname lookup

It is quite unfortunate that kernel developers insist on extending openat() with more and more contrived semantics, I wish they just added new syscalls with well defined behaviour.

to post comments

New AT_ flags for restricting pathname lookup

Posted Oct 7, 2018 4:36 UTC (Sun) by cyphar (subscriber, #110703) [Link]

Something like resolveat(2)? The problem is that this would necessarily be conceptually identical to openat(O_PATH). Maybe O_PATH should've been a different syscall but we are mostly stuck with it now, and I think it would be strange to have two methods of opening an O_PATH descriptor. Though, there are some aspects of O_PATH that I think need to be fixed (and would require more convoluted O_ flags -- maybe a new syscall is warranted to fix some of the semantics of O_PATH. I'm not sure.)

And remember that the widespread utility of any resolveat(2) syscall would likely require having AT_EMPTY_PATH support for every *at(2) syscall (which is unfortunately far from the case currently).