File Manager Service in OpenBMC

File Manager Service in OpenBMC

[Sunitha Harish]

Hi,

This email is about adding a FileManager Service in OpenBMC.

IBM has usecases implemented under /ibm/v1 path at bmcweb, which uploads 
and manages files on the BMC. This usecase is being re-designed, to stop 
bmcweb from modifying and accessing BMC file system directly.

To achieve this, a dbus & backend application is needed. This should 
provide APIs to Create, Update, Get and Delete a file. This application 
should also take care of security aspects of the File upload usecases, 
before letting the BMC file system updated. Please share your views on 
adding this application.

Thanks & regards,
Sunitha

Re: File Manager Service in OpenBMC

[Andrew Jeffery]

On Thu, 2024-02-08 at 12:52 +0530, Sunitha Harish wrote:
> Hi,
> 
> This email is about adding a FileManager Service in OpenBMC.
> 
> IBM has usecases implemented under /ibm/v1 path at bmcweb, which uploads 
> and manages files on the BMC. This usecase is being re-designed, to stop 
> bmcweb from modifying and accessing BMC file system directly.
> 
> To achieve this, a dbus & backend application is needed. This should 
> provide APIs to Create, Update, Get and Delete a file. This application 
> should also take care of security aspects of the File upload usecases, 
> before letting the BMC file system updated. Please share your views on 
> adding this application.

I'm struggling to make sense of this.

What are we actually trying to achieve? If bmcweb can indirectly write
arbitrary files through this service there's no advantage. Instead we
have a whole bunch of complexity and overhead.

It feels like the GPIO conversation that we seem to have periodically
in the project. I think we need more information on *the use* of the
files you need to upload.

Andrew

Re: File Manager Service in OpenBMC

[Sunitha Harish]

Thank you Andrew for the reply.

When IBM manages a single server with multiple management 
clients(redfish clients), they need to save some server related data 
(host data) in the form of files at BMC's persistent file system. Here 
BMC is used as a common persistent storage, which is accessible to all 
connected redfish clients.

Additionally, for IBM usecase, BMC need not consume these files, as they 
are targeted to be used by the host/hypervisor. We control the file 
permissions accordingly to make it non-executable at BMC. We already 
have a implementation at the bmcweb currently at 
https://github.com/openbmc/bmcweb/blob/master/include/ibm/management_console_rest.hpp. 
This is being re-designing as i mentioned in previous email.

If community is interested to have a File Manager running in BMC, then 
this re-design can be a generic solution.

Thanks & regards,
Sunitha


On 09/02/24 4:48 am, Andrew Jeffery wrote:
> On Thu, 2024-02-08 at 12:52 +0530, Sunitha Harish wrote:
>> Hi,
>>
>> This email is about adding a FileManager Service in OpenBMC.
>>
>> IBM has usecases implemented under /ibm/v1 path at bmcweb, which uploads
>> and manages files on the BMC. This usecase is being re-designed, to stop
>> bmcweb from modifying and accessing BMC file system directly.
>>
>> To achieve this, a dbus & backend application is needed. This should
>> provide APIs to Create, Update, Get and Delete a file. This application
>> should also take care of security aspects of the File upload usecases,
>> before letting the BMC file system updated. Please share your views on
>> adding this application.
> I'm struggling to make sense of this.
>
> What are we actually trying to achieve? If bmcweb can indirectly write
> arbitrary files through this service there's no advantage. Instead we
> have a whole bunch of complexity and overhead.
>
> It feels like the GPIO conversation that we seem to have periodically
> in the project. I think we need more information on *the use* of the
> files you need to upload.
>
> Andrew
>

Re: File Manager Service in OpenBMC

[Andrew Jeffery]

Hi Sunitha,

On Fri, 2024-02-09 at 11:23 +0530, Sunitha Harish wrote:
> Thank you Andrew for the reply.
> 
> When IBM manages a single server with multiple management 
> clients(redfish clients), they need to save some server related data 
> (host data) in the form of files at BMC's persistent file system.
> 

What are the specific use-cases though? It seems that we've jumped
straight to an implementation detail (persisted files) when it's not
clear to me *what* it is that's needing to be communicated to begin
with.

>  Here 
> BMC is used as a common persistent storage, which is accessible to all 
> connected redfish clients.

Okay, but why is that necessary? Can you please enumerate the use-
cases?

The use-cases are what allows us to find an intersection of interests
with others in the community.

Discussions in the abstract in the context of a specific implementation
approach feel to me like they might struggle to gain traction.

> 
> Additionally, for IBM usecase, BMC need not consume these files, as they 
> are targeted to be used by the host/hypervisor. 
> 

If they're not used by the BMC can you unpack why they need to be
stored on the BMC?

Andrew

Re: File Manager Service in OpenBMC

[Sunitha Harish]

[-- Attachment #1: Type: text/plain, Size: 2349 bytes --]


On 12/02/24 3:45 am, Andrew Jeffery wrote:
> Hi Sunitha,
>
> On Fri, 2024-02-09 at 11:23 +0530, Sunitha Harish wrote:
>> Thank you Andrew for the reply.
>>
>> When IBM manages a single server with multiple management
>> clients(redfish clients), they need to save some server related data
>> (host data) in the form of files at BMC's persistent file system.
>>
> What are the specific use-cases though? It seems that we've jumped
> straight to an implementation detail (persisted files) when it's not
> clear to me *what* it is that's needing to be communicated to begin
> with.

IBM has usecases implemented under /ibm/v1 path at bmcweb, which uploads and manages files on the BMC.
These are APIs to Create, Update, Get and Delete a file.
The data which needs to be persisted in the BMC are considerably big enough - that can not be modeled via DBus properties.
Moreover, the data which is stored are meant to be interpreted by the host & the client who is managing the host via this BMC.
So the preferred way of storing this is files.

>>   Here
>> BMC is used as a common persistent storage, which is accessible to all
>> connected redfish clients.
> Okay, but why is that necessary? Can you please enumerate the use-
> cases?
>
> The use-cases are what allows us to find an intersection of interests
> with others in the community.
>
> Discussions in the abstract in the context of a specific implementation
> approach feel to me like they might struggle to gain traction.

This is the primary usecase of IBM. But, if there are any other way of getting this done in a any other way, please suggest and we can work together on that.
With this email, i am actually looking for someone who may have similar usecase of providing the user a facility to manage files at BMC.

>> Additionally, for IBM usecase, BMC need not consume these files, as they
>> are targeted to be used by the host/hypervisor.
>>
> If they're not used by the BMC can you unpack why they need to be
> stored on the BMC?

Customers setup the systems such that, multiple management clients (primary & backup) can manage a single BMC. There will be some host data, which are needed in common to
both the primary and backup management consoles consumption. The best place to persist them is at BMC. Customer need not buy another trusted storage area to save the data.

>
> Andrew

[-- Attachment #2: Type: text/html, Size: 3738 bytes --]

Re: File Manager Service in OpenBMC

[Andrew Jeffery]

Hi Sunitha,

On Mon, 2024-02-12 at 20:34 +0530, Sunitha Harish wrote:
> On 12/02/24 3:45 am, Andrew Jeffery wrote:
> > Hi Sunitha,
> > 
> > On Fri, 2024-02-09 at 11:23 +0530, Sunitha Harish wrote:
> > > Thank you Andrew for the reply.
> > > 
> > > When IBM manages a single server with multiple management
> > > clients(redfish clients), they need to save some server related data
> > > (host data) in the form of files at BMC's persistent file system.
> > > 
> > What are the specific use-cases though? It seems that we've jumped
> > straight to an implementation detail (persisted files) when it's not
> > clear to me *what* it is that's needing to be communicated to begin
> > with.
> 
> IBM has usecases implemented under /ibm/v1 path at bmcweb, which uploads and manages files on the BMC.
> These are APIs to Create, Update, Get and Delete a file.

These aren't what I consider use cases though, IMO they're behaviours
you might need for an implementation of something supporting a use-
case.

Given you have files, what is their purpose? Why would someone upload
one? Who is it that's uploading the file? What are they trying to
achieve? What's their motivation? Can you enumerate those reasons?

> 
> > 
> > Discussions in the abstract in the context of a specific implementation
> > approach feel to me like they might struggle to gain traction.
> 
> This is the primary usecase of IBM.
> 

But it's not something I'd categorise as a use-case. It's a specific
implementation strategy for something else, where the something else is
probably the use-case I'm asking you to describe. Use-cases should
involve discussions of actors trying to achieve an outcome with a
system. Who are the actors? What are the outcomes they're trying to
achieve with the system?

>  But, if there are any other way of getting this done in a any other way, please suggest and we can work together on that.

I'm unsure, because I don't feel like I have a solid grip on what the
use-cases are, in terms of what someone would be trying to achieve with
the system.

> With this email, i am actually looking for someone who may have similar usecase of providing the user a facility to manage files at BMC.

I'm hoping that by clarifying what your use-cases are it's easier for
people who may have similar use-cases to identify themselves. It would
certainly help me be satisfied that re-implementing a filesystem on top
of DBus is sensible, because on the surface it doesn't feel like it is.

Andrew

Re: File Manager Service in OpenBMC

[Sunitha Harish]

[-- Attachment #1: Type: text/plain, Size: 2948 bytes --]

Hi Andrew,

On 13/02/24 4:06 am, Andrew Jeffery wrote:
> Hi Sunitha,
>
> On Mon, 2024-02-12 at 20:34 +0530, Sunitha Harish wrote:
>> On 12/02/24 3:45 am, Andrew Jeffery wrote:
>>> Hi Sunitha,
>>>
>>> On Fri, 2024-02-09 at 11:23 +0530, Sunitha Harish wrote:
>>>> Thank you Andrew for the reply.
>>>>
>>>> When IBM manages a single server with multiple management
>>>> clients(redfish clients), they need to save some server related data
>>>> (host data) in the form of files at BMC's persistent file system.
>>>>
>>> What are the specific use-cases though? It seems that we've jumped
>>> straight to an implementation detail (persisted files) when it's not
>>> clear to me *what* it is that's needing to be communicated to begin
>>> with.
>> IBM has usecases implemented under /ibm/v1 path at bmcweb, which uploads and manages files on the BMC.
>> These are APIs to Create, Update, Get and Delete a file.
> These aren't what I consider use cases though, IMO they're behaviours
> you might need for an implementation of something supporting a use-
> case.
>
> Given you have files, what is their purpose? Why would someone upload
> one? Who is it that's uploading the file? What are they trying to
> achieve? What's their motivation? Can you enumerate those reasons?

I have mentioned the purpose of this usecase already. There is no more details that i can share.

>>> Discussions in the abstract in the context of a specific implementation
>>> approach feel to me like they might struggle to gain traction.
>> This is the primary usecase of IBM.
>>
> But it's not something I'd categorise as a use-case. It's a specific
> implementation strategy for something else, where the something else is
> probably the use-case I'm asking you to describe. Use-cases should
> involve discussions of actors trying to achieve an outcome with a
> system. Who are the actors? What are the outcomes they're trying to
> achieve with the system?
>
>>   But, if there are any other way of getting this done in a any other way, please suggest and we can work together on that.
> I'm unsure, because I don't feel like I have a solid grip on what the
> use-cases are, in terms of what someone would be trying to achieve with
> the system.
>
>> With this email, i am actually looking for someone who may have similar usecase of providing the user a facility to manage files at BMC.
> I'm hoping that by clarifying what your use-cases are it's easier for
> people who may have similar use-cases to identify themselves. It would
> certainly help me be satisfied that re-implementing a filesystem on top
> of DBus is sensible, because on the surface it doesn't feel like it is.

Its not about implementing the file system on the BMC. Its implementing a systemd service, which will host the file descriptors as dbus
interfaces/properties. This will give file handler APIs to the redfish clients who are willing to do file operations on the BMC.

>
> Andrew

Regards,
Sunitha

[-- Attachment #2: Type: text/html, Size: 4673 bytes --]

Re: File Manager Service in OpenBMC

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 1807 bytes --]

On Tue, Feb 13, 2024 at 12:14:49PM +0530, Sunitha Harish wrote:

> I have mentioned the purpose of this usecase already. There is no more details that i can share.

I think we're missing the high-level premise of what you're
proposing.  Is this an arbitrary "expose the file system over dbus" or
does it have some very specific purpose?  You've said something along
the lines of "there are some files for the manage host", which is mostly
fine if you don't want to talk about the details of them (even though
they are supposedly already in bmcweb?) but I think there are still some
more specifics you can talk to.

> Its not about implementing the file system on the BMC. Its implementing a systemd service, which will host the file descriptors as dbus
> interfaces/properties. This will give file handler APIs to the redfish clients who are willing to do file operations on the BMC.

My first read on this is that all it is doing is moving the problem from
one place to another.  Fundamentally, the reason to not have bmcweb do
file access is because of the potential security concerns.  Having a
generic dbus service that reads and modifies the file system has the
exact same security concerns, except now you've potentially lost all
information as to _who_ is doing the file operation (unless you add who
is doing the operation to the dbus interface).

If the proposal is "make a generic daemon that can expose the whole file
system as a dbus-service", the answer is likely "no" due to all the
security implications.  If there are specific files, folders, and/or
configurable sets (which by default is a locked down set of nearly
nothing) then "maybe"?  This is where it seems like people would need to
see more details of what you're accomplishing.

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: File Manager Service in OpenBMC

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 900 bytes --]

On Thu, Feb 08, 2024 at 12:52:11PM +0530, Sunitha Harish wrote:
> This usecase is being re-designed, to stop 
> bmcweb from modifying and accessing BMC file system directly.

Why?  What motivated this?

> To achieve this, a dbus & backend application is needed. This should 
> provide APIs to Create, Update, Get and Delete a file. This application 
> should also take care of security aspects of the File upload usecases, 
> before letting the BMC file system updated. Please share your views on 
> adding this application.

What are the "security aspects"?  This is a very broad statement and
feels a bit hand-wavy.

I'm not really sure what views you expected anyone to give.  There are
basically 2 sentences of details here.  My gut reaction is "this sounds
like a CVE waiting to happen", but, if you want to write a design
document proposal go ahead.

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: File Manager Service in OpenBMC

[Sunitha Harish]

[-- Attachment #1: Type: text/plain, Size: 3048 bytes --]

Hi Patrick,

Thanks for the reply.

On 13/02/24 8:02 pm, Patrick Williams wrote:
> On Tue, Feb 13, 2024 at 12:14:49PM +0530, Sunitha Harish wrote:
>
>> I have mentioned the purpose of this usecase already. There is no more details that i can share.
> I think we're missing the high-level premise of what you're
> proposing.  Is this an arbitrary "expose the file system over dbus" or
> does it have some very specific purpose?  You've said something along
> the lines of "there are some files for the manage host", which is mostly
> fine if you don't want to talk about the details of them (even though
> they are supposedly already in bmcweb?) but I think there are still some
> more specifics you can talk to.

This is not exposing the whole file system over dbus. Specific persistent directory path only needs to be exposed.

Files content are not interpreted by BMC. They contain the system configuration details & resource data which gets loaded on top of the hypervisor.
These data are needed by the backup management console (redfish client) when it takes over the system management, when there is any failures on the
primary management console. IBM's management console implements the logic to read/write to these files, and only this client and the hypervisor understands the
format and data in this file.

>> Its not about implementing the file system on the BMC. Its implementing a systemd service, which will host the file descriptors as dbus
>> interfaces/properties. This will give file handler APIs to the redfish clients who are willing to do file operations on the BMC.
> My first read on this is that all it is doing is moving the problem from
> one place to another.  Fundamentally, the reason to not have bmcweb do
> file access is because of the potential security concerns.  Having a
> generic dbus service that reads and modifies the file system has the
> exact same security concerns, except now you've potentially lost all
> information as to _who_ is doing the file operation (unless you add who
> is doing the operation to the dbus interface).

Yes. Current implementation creates files with 700 permission. Only admin can upload the files.
In this app, there should be the validations for ensuring the security aspects. I will list them in design, and can be enhanced during review.
Adding the session id to the dbus would be a good audit data.

> If the proposal is "make a generic daemon that can expose the whole file
> system as a dbus-service", the answer is likely "no" due to all the
> security implications.  If there are specific files, folders, and/or
> configurable sets (which by default is a locked down set of nearly
> nothing) then "maybe"?  This is where it seems like people would need to
> see more details of what you're accomplishing.

I got it. Whole file system as a dbus-service is not expected here. This a specific persistent path at the BMC.
This can be thought as a small, limited sized storage place which can be shared between the redfish clients who are managing the BMC.

Regards,
Sunitha

[-- Attachment #2: Type: text/html, Size: 4227 bytes --]

Re: File Manager Service in OpenBMC

[Sunitha Harish]

[-- Attachment #1: Type: text/plain, Size: 1694 bytes --]


On 13/02/24 8:05 pm, Patrick Williams wrote:
> On Thu, Feb 08, 2024 at 12:52:11PM +0530, Sunitha Harish wrote:
>> This usecase is being re-designed, to stop
>> bmcweb from modifying and accessing BMC file system directly.
> Why?  What motivated this?

This is being worked due to Ed's concern over the bmcweb design of IBM Management console APIs.
We will be removing the current bmcweb implementation and moving towards a dbus app based file
operations to make the design in-line with any other BMC features.

>> To achieve this, a dbus & backend application is needed. This should
>> provide APIs to Create, Update, Get and Delete a file. This application
>> should also take care of security aspects of the File upload usecases,
>> before letting the BMC file system updated. Please share your views on
>> adding this application.
> What are the "security aspects"?  This is a very broad statement and
> feels a bit hand-wavy.

Security aspects include the storage path, size and the directory & file sizes, contents, permissions etc.

> I'm not really sure what views you expected anyone to give.  There are
> basically 2 sentences of details here.  My gut reaction is "this sounds
> like a CVE waiting to happen", but, if you want to write a design
> document proposal go ahead.
>
Agree, this app would allow the file uploads to the BMC. Thus a threat model and validations of the incoming data should be in place.

There is no DMTF schema available to do the file operations.
I have initiated a thread at DMTF athttps://redfishforum.com/thread/1014/file-collection-resource  
Current plan is to retain IBM OEM REST path /ibm/v1; which will invoke the APIs provided by this file manager.

[-- Attachment #2: Type: text/html, Size: 2818 bytes --]