|
|
Subscribe / Log in / New account

New AT_ flags for restricting pathname lookup

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).


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds