On Wed, Sep 4, 2024 at 4:28 PM Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote:
> On 9/4/2024 1:00 PM, Paul Moore wrote:
> > On Tue, Sep 3, 2024 at 8:53 PM Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote:
> >> On 9/3/2024 5:18 PM, Paul Moore wrote:
> >>> On Aug 29, 2024 Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote:
> > ..
> >
> >>>> +/*
> >>>> + * Data exported by the security modules
> >>>> + */
> >>>> +struct lsmblob {
> >>>> + struct lsmblob_selinux selinux;
> >>>> + struct lsmblob_smack smack;
> >>>> + struct lsmblob_apparmor apparmor;
> >>>> + struct lsmblob_bpf bpf;
> >>>> + struct lsmblob_scaffold scaffold;
> >>>> +};
> >>> Warning, top shelf bikeshedding follows ...
> >> Not unexpected. :)
> >>
> >>> I believe that historically when we've talked about the "LSM blob" we've
> >>> usually been referring to the opaque buffers used to store LSM state that
> >>> we attach to a number of kernel structs using the `void *security` field.
> >>>
> >>> At least that is what I think of when I read "struct lsmblob", and I'd
> >>> like to get ahead of the potential confusion while we still can.
> >>>
> >>> Casey, I'm sure you're priority is simply getting this merged and you
> >>> likely care very little about the name (as long as it isn't too horrible),
> >> I would reject lsmlatefordinner out of hand.
> > Fair enough :)
> >
> >>> but what about "lsm_ref"? Other ideas are most definitely welcome.
> >> I'm not a fan of the underscore, and ref seems to imply memory management.
> >> How about "struct lsmsecid", which is a nod to the past "u32 secid"?
> >> Or, "struct lsmdata", "struct lsmid", "struct lsmattr".
> >> I could live with "struct lsmref", I suppose, although it pulls me toward
> >> "struct lsmreference", which is a bit long.
> > For what it's worth, I do agree that "ref" is annoyingly similar to a
> > reference counter, I don't love it here, but I'm having a hard time
> > coming up with something appropriate.
> >
> > I also tend to like the underscore, at least in the struct name, as it
> > matches well with the "lsm_ctx" struct we have as part of the UAPI.
> > When we use the struct name in function names, feel free to drop the
> > underscore, for example: "lsm_foo" -> "security_get_lsmfoo()".
> >
> > My first thought was for something like "lsmid" (ignoring the
> > underscore debate), but we already have the LSM_ID_XXX defines which
> > are something entirely different and I felt like we would be trading
> > one source of confusion for another. There is a similar problem with
> > the LSM_ATTR_XXX defines.
> >
> > We also already have a "lsm_ctx" struct which sort of rules out
> > "lsmctx" for what are hopefully obvious reasons.
> >
> > I'd also like to avoid anything involving "secid" or "secctx" simply
> > because the whole point of this struct is to move past the idea of a
> > single integer or string representing all of the LSM properties for an
> > entity.
> >
> > I can understand "lsm_data", but that is more ambiguous than I would like.
> >
> > What about "lsm_prop" or "lsm_cred"?
>
> If we ever do the same sort of thing for the existing blobs we're
> going to need to have lsm_cred for the cred blob, so I shan't use
> it here. I can live with lsm_prop, which shouldn't confuse too many
> developers. We can start saying "property" in place of secid, which
> would be a good thing.
Works for me, thanks Casey.
--
paul-moore.com
