<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<pre>Hi Patrick,</pre>
<pre>Thanks for the reply.
</pre>
<div class="moz-cite-prefix">On 13/02/24 8:02 pm, Patrick Williams
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:Zct9feAKEIiDonzu@heinlein.vulture-banana.ts.net">
<pre class="moz-quote-pre" wrap="">On Tue, Feb 13, 2024 at 12:14:49PM +0530, Sunitha Harish wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">I have mentioned the purpose of this usecase already. There is no more details that i can share.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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.
</pre>
</blockquote>
<pre>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.
</pre>
<blockquote type="cite"
cite="mid:Zct9feAKEIiDonzu@heinlein.vulture-banana.ts.net">
<pre class="moz-quote-pre" wrap="">
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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).
</pre>
</blockquote>
<pre>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.
</pre>
<blockquote type="cite"
cite="mid:Zct9feAKEIiDonzu@heinlein.vulture-banana.ts.net">
<pre class="moz-quote-pre" wrap="">
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.
</pre>
</blockquote>
<pre>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.
</pre>
<blockquote type="cite"
cite="mid:Zct9feAKEIiDonzu@heinlein.vulture-banana.ts.net">
<pre class="moz-quote-pre" wrap="">
</pre>
</blockquote>
<pre>Regards,
Sunitha
</pre>
</body>
</html>