File Manager Service in OpenBMC

[Sunitha Harish]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20240214/833fb486/attachment.htm>