On 9/4/2024 1:00 PM, Paul Moore wrote:

On Tue, Sep 3, 2024 at 8:53 PM Casey Schaufler [off-list ref] wrote:

quoted

On 9/3/2024 5:18 PM, Paul Moore wrote:

quoted

On Aug 29, 2024 Casey Schaufler [off-list ref] wrote:

..

quoted

quoted

quoted

+/*
+ * 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. :)

quoted

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 :)

quoted

quoted

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.