On Mon, Apr 04, 2022 at 10:30:13PM +0200, Mickaël Salaün wrote: > > If you add a new X_OK variant to access(), maybe that could fly. > > As answered in private, that was the approach I took for one of the early > versions but a dedicated syscall was requested by Al Viro: > https://lore.kernel.org/r/2ed377c4-3500-3ddc-7181-a5bc114ddf94@xxxxxxxxxxx > The main reason behind this request was that it doesn't have the exact same > semantic as faccessat(2). The changes for this syscall are documented here: > https://lore.kernel.org/all/20220104155024.48023-3-mic@xxxxxxxxxxx/ > The whole history is linked in the cover letter: > https://lore.kernel.org/all/2ed377c4-3500-3ddc-7181-a5bc114ddf94@xxxxxxxxxxx/ As a suggestion, something that can be helpful for something which has been as heavily bike-sheded as this concept might be to write a "legislative history", or perhaps, a "bike shed history". And not just with links to mailing list discussions, but a short summary of why, for example, we moved from the open flag O_MAYEXEC to the faccessat(2) approach. I looked, but I couldn't find the reasoning while diving into the mail archives. And there was some kind of request for some new functionality for IMA and other LSM's that I couldn't follow that is why the new AT_INTERETED flag, but at this point my time quantuum for mailing list archeology most definitely expired. :-) It might be that when all of this is laid out, we can either revisit prior design decisions as "that bike-shed request to support this corner case was unreasonable", or "oh, OK, this is why we need as fully general a solution as this". Also, some of examples of potential future use cases such as "magic links" that were linked in the cover letter, it's not clear to me actually make sense in the context of a "trusted for" system call (although might make more sense in the context of an open flag). So revisiting some of those other cases to see whether they actually *could* be implemented as new "TRUSTED_FOR" flags might be instructive. Personally, I'm a bit skeptical about the prospct of additional use cases, since trusted_for(2) is essentially a mother_should_I(2) request where userspace is asking the kernel whether they should go ahead and do some particular policy thing. And it's not clear to me how many of these policy questions exist where (a) the kernel is in the past position to answer that question, and (b) there isn't some additional information that the kernel doesn't have that might be needed to answer that question. For example, "Mother should I use that private key file" might require information about whether the SRE is currently on pager duty or not, at least for some policies, and the kernel isn't going to have that information. Other examples of TRUSTED_FOR flags that really make sense and would be useful might help alleviate my skepticsm. And the "bike shed history" would help with my question about why some folks didn't like the original O_MAYEXEC flag? Cheers, - Ted
