Messages in this thread | | | Date | Tue, 5 Apr 2022 18:14:05 +0200 | From | Mickaël Salaün <> | Subject | Re: [GIT PULL] Add trusted_for(2) (was O_MAYEXEC) |
| |
On 05/04/2022 16:54, Theodore Ts'o wrote: > 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@digikod.net >> 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@digikod.net/ >> The whole history is linked in the cover letter: >> https://lore.kernel.org/all/2ed377c4-3500-3ddc-7181-a5bc114ddf94@digikod.net/ > > 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)
That would be an interesting syscall name. ;)
> 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.
Script execution is definitely the main use case and the semantic is already known by the kernel.
> > 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?
Thanks, I'll do some that.
> > Cheers, > > - Ted
| |