lkml.org 
[lkml]   [2022]   [Apr]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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

\
 
 \ /
  Last update: 2022-04-05 23:13    [W:0.133 / U:2.172 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site