where to store application json

[Joseph Reynolds]

On 8/16/19 8:31 AM, Matt Spinler wrote:
>
> On 8/15/2019 6:59 PM, Andrew Jeffery wrote:
>>
>> On Fri, 16 Aug 2019, at 07:01, Andrew Geissler wrote:
>>> As we start moving more and more of our applications to using 
>>> runtime parsed
>>> json files, it seems like a good time to come up with a standard 
>>> location to put
>>> the json files. I think a requirement is they be in a writeable 
>>> filesystem
>>> (although that may bring security concerns) so that you can edit and 
>>> restart
>>> services that use them on the fly for bringup and debug.
>>>
>>> /etc seems like the right spot. But if so, where in /etc
>
> While convenient to the developer for testing, to me it doesn't sound 
> like good practice to put read
> only, critical files into a writeable spot?  How could we even trust 
> data that comes back to us from
> the field when a user that can get into their BMC can just change 
> these?  Or accidentally
> delete a file?
>

One security concern is that config files offer a good way for hackers 
to get persistent access to the system.  That is, if they are able to 
get root access to the BMC one time, they may be able to persist their 
hack across BMC reboots by modifying some config files.  IMHO, to make 
it harder for them, as much as possible of the file system should be 
read-only, and read-write config files should not offer the above 
mentioned service to hackers.

My 2 cents,
- Joseph

>
>
>>> ?
>>>
>>> Adriana pointed me to the FSH guidelines[1] in a review which has 
>>> the following:
>>> "It is recommended that files be stored in subdirectories of /etc 
>>> rather than
>>> directly in /etc.".
>>>
>>> /etc/opt ?
>>> /etc/opt/phosphor/ ?
>>> /etc/opt/phosphor/<repository name>/ ?
>> Where did the "/opt/" bit come from? Please lets drop that.
>>
>> IMO we should be using /etc/<application name>. Be mindful that one 
>> repository
>> can produce multiple applications, but what application sits in which 
>> repository
>> is a code organisation problem and not something that we should tie 
>> into system
>> configuration.
>>
>> Andrew
>