Re: [GIT PULL] Add trusted_for(2) (was O_MAYEXEC)

[Mickaël Salaün]

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

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