On Fri, 2024-06-21 at 17:19 -0400, Paul Moore wrote: > 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. Ok, so no problem from my side to upstream the patch. My only comment would be that I would not call the new functions with the ima_ prefix, being those in security.c, which is LSM agnostic, but I would rather use a name that more resembles the differences, if any. If not: Acked-by: Roberto Sassu <roberto.sassu@xxxxxxxxxx> Thanks Roberto
