On Fri, Oct 11, 2024 at 12:34 PM Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote: > On 10/11/2024 9:11 AM, Paul Moore wrote: > > On Fri, Oct 11, 2024 at 11:52 AM Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote: > >> On 10/10/2024 8:08 PM, Paul Moore wrote: > >>> On Oct 9, 2024 Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote: > >>>> Replace the secid value stored in struct audit_context with a struct > >>>> lsm_prop. Change the code that uses this value to accommodate the > >>>> change. security_audit_rule_match() expects a lsm_prop, so existing > >>>> scaffolding can be removed. A call to security_secid_to_secctx() > >>>> is changed to security_lsmprop_to_secctx(). The call to > >>>> security_ipc_getsecid() is scaffolded. > >>>> > >>>> A new function lsmprop_is_set() is introduced to identify whether > >>>> an lsm_prop contains a non-zero value. > >>>> > >>>> Signed-off-by: Casey Schaufler <casey@xxxxxxxxxxxxxxxx> > >>>> --- > >>>> include/linux/security.h | 24 ++++++++++++++++++++++++ > >>>> kernel/audit.h | 3 ++- > >>>> kernel/auditsc.c | 19 ++++++++----------- > >>>> 3 files changed, 34 insertions(+), 12 deletions(-) > > .. > > > >>>> +/** > >>>> + * lsmprop_is_set - report if there is a value in the lsm_prop > >>>> + * @prop: Pointer to the exported LSM data > >>>> + * > >>>> + * Returns true if there is a value set, false otherwise > >>>> + */ > >>>> +static inline bool lsm_prop_is_set(struct lsm_prop *prop) > >>>> +{ > >>>> + return false; > >>>> +} > >>> If we're going to call this lsmprop_is_set() (see 5/13), we really should > >>> name it that way to start in this patch. > >> Agreed. That's an unfortunate artifact of the lsmblob to lsm_prop name change. > >> > >>> Considering everything else in this patchset looks okay, if you want me > >>> to fix this up during the merge let me know. > >> I can do a v5 if that makes life easier, but if you're OK with fixing it > >> during the merge I'm completely fine with that. Thank you. > > For trivial things like this where I've already reviewed the full > > patchset it's easier/quicker if I just make the change as I can do it > > and not have to re-review everything. Otherwise it's another revision > > for you to post, me to review, etc.; granted in that case I'm really > > just diffing between v4 and v5, not really doing a full review unless > > something odd pops up in the diff, but I think you get the idea. > > Indeed. Go forth and merge. Thanks again. ... and now everything is merged into lsm/dev, thanks everyone! -- paul-moore.com