On Fri, Jun 21, 2024 at 4:34 PM Roberto Sassu <roberto.sassu@xxxxxxxxxxxxxxx> wrote: > On 6/21/2024 10:23 PM, Mimi Zohar wrote: > > On Fri, 2024-06-21 at 15:07 -0400, Paul Moore wrote: > >> On Fri, Jun 21, 2024 at 12:50 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > >>> On Fri, Dec 15, 2023 at 5:16 PM Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote: > >>>> Create real functions for the ima_filter_rule interfaces. > >>>> These replace #defines that obscure the reuse of audit > >>>> interfaces. The new functions are put in security.c because > >>>> they use security module registered hooks that we don't > >>>> want exported. > >>>> > >>>> Acked-by: Paul Moore <paul@xxxxxxxxxxxxxx> > >>>> Reviewed-by: John Johansen <john.johansen@xxxxxxxxxxxxx> > >>>> Signed-off-by: Casey Schaufler <casey@xxxxxxxxxxxxxxxx> > >>>> To: Mimi Zohar <zohar@xxxxxxxxxxxxx> > >>>> Cc: linux-integrity@xxxxxxxxxxxxxxx > >>>> --- > >>>> include/linux/security.h | 24 ++++++++++++++++++++++++ > >>>> security/integrity/ima/ima.h | 26 -------------------------- > >>>> security/security.c | 21 +++++++++++++++++++++ > >>>> 3 files changed, 45 insertions(+), 26 deletions(-) > >>> > >>> Mimi, Roberto, are you both okay if I merge this into the lsm/dev > >>> branch? The #define approach taken with the ima_filter_rule_XXX > >>> macros likely contributed to the recent problem where the build > >>> problem caused by the new gfp_t parameter was missed during review; > >>> I'd like to get this into an upstream tree independent of the larger > >>> stacking effort as I believe it has standalone value. > >> > >> ... and I just realized neither Mimi or Roberto were directly CC'd on > >> that last email, oops. Fixed. > > > > Paul, I do see things posted on the linux-integrity mailing list pretty quickly. > > Unfortunately, something came up midday and I'm just seeing this now. As for > > Roberto, it's probably a time zone issue. > > Will review/check it first thing Monday morning. Thanks Roberto, no rush. -- paul-moore.com
