Yeah, an easier formulation would be: noveil(...) to mark pathes we plan to use (fails on veiled pathes), and a subsequent veil() that irreversibly removes acc

Yeah, an easier formulation would be: noveil(...) to mark pathes we plan to use (fails on veiled pathes), and a subsequent veil() that irreversibly removes access to everything that was not protected by a noveil(...) call between this and the last veil() call. If a veil() call never comes, well, then we did not restrict access at all and only spammed some kernel structure. If all you care is protection in case someone gets codeexec in your process, then this would be simpler and give additional features (we can incrementally drop access, instead of only once). I see an advantage of the unveil(...) in that: Suppose my process cannot irrevocably drop access, because e.g. it anticipates to need to write to some pathes we don't know already. But still, the unveil can help to mitigate stuff like directory traversals: I can't lock (unveil(0,0)), so codeexec is still game over; if my code for late unveiling has bugs it's game over; but if the late unveiling code has no bugs, but the actual file access code is buggy, then this construction will protect me.