Re: [PATCH 2/4] fs: define a firmware security filesystem named fwsecurityfs

On 11/20/22 22:14, James Bottomley wrote:

On Sun, 2022-11-20 at 17:13 +0100, Greg Kroah-Hartman wrote:

quoted

On Sat, Nov 19, 2022 at 01:20:09AM -0500, Nayna wrote:

quoted

On 11/17/22 16:27, Greg Kroah-Hartman wrote:

quoted

On Mon, Nov 14, 2022 at 06:03:43PM -0500, Nayna wrote:

quoted

On 11/10/22 04:58, Greg Kroah-Hartman wrote:

[...]

quoted

quoted

[...]

quoted

quoted

You are correct. There's no namespace for these.

So again, I do not understand.  Do you want to use filesystem
namespaces, or do you not?

Since this seems to go back to my email quoted again, let me repeat:
the question isn't if this patch is namespaced; I think you've agreed
several times it isn't.  The question is if the exposed properties
would ever need to be namespaced.  This is a subtle and complex
question which isn't at all explored by the above interchange.

quoted

How again can you not use sysfs or securityfs due to namespaces?
What is missing?

I already explained in the email that sysfs contains APIs like
simple_pin_... which are completely inimical to namespacing.  Currently
securityfs contains them as well, so in that regard they're both no
better than each other.  The point I was making is that securityfs is
getting namespaced by the IMA namespace rework (which is pretty complex
due to having to replace the simple_pin_... APIs), so when (perhaps if)
the IMA namespace is accepted, securityfs will make a good home for
quantities that need namespacing.  That's not to say you can't
namespace things in sysfs, you can, in the same way that you can get a
round peg into a square hole if you bang hard enough.

So perhaps we could get back to the original question of whether these
quantities would ever be namespaced ... or, conversely, whether they
would never need namespacing.

To clarify, I brought up in the discussion about namespacing considerations because I was asked about them. However, I determined there were none because firmware object interactions are invariant across namespaces.  I don't see this changing in the future given that the firmware objects have no notion of namespacing.

Thanks & Regards,

    - Nayna