System vs User file/directory precedence

[gokarnm]

The directory structure spec defines system and user level directory paths. When both paths are present, it may be required to give precedence to system or user level based on specific scenarios.

• User level setting in config.json and signingkeys.json may take precedence over system level settings in development scenarios, or an environment shared by multiple users.
• In deployment scenarios, it may be desirable to use system level trustpolicy.json and trust store, even if an user level (application or service role) trust store and policy exists, to allow administrator roles to enforce usage of trust policy and store.

We should come up with an approach that is flexible to support both scenarios.

[iamsamirzon]

@gokarnm thinks we can start directory spec implementation while working in parallel to close this. This is not a blocker to start.

[gokarnm]

Here is a proposal for how to address this.

1. Only in the system level config.json we provide a new setting configurationBehavior with supported values user/system which allows a system admin role to setup preferred configuration priority, which cannot be overriden by a user role. This setting applies to all files/directories (config.json, signingkeys.json, plugin dir, trustpolicy.json, trust store dir etc.)
2. The default value of this setting if unspecified is user, so default behavior is user level files/directories take precedence over system level if both are present.

system - only system level settings are applied, user level settings are ignored in all cases, even when a specific setting is missing at system level and present at user level.
user - user level files/directories take precedence over system level if both are present.

Thoughts? @shizhMSFT @SteveLasker @priteshbandi @rgnote

[iamsamirzon]

As per @gokarnm , this is not a blocker to start implementation.

[dtzar]

Related to #175 and #167

[dtzar]

@junjie

[JeyJeyGao]

I will add a comment to the related code to mention that the implementation may be changed later.

[SteveLasker]

Thanks for capturing this @gokarnm
Balancing usability and security, this is one of those places where I'd suggest we need to lean a bit more to the security side, with a "secure by default" posture. If we leave the default to be user overrides, then we must assume most deployments will allow users to change the behavior, including default configurations of system configurations, where we are most exposed to "hacking".

What I'd suggest is we default system and force users to change to user if they really need it.

[SteveLasker]

Who owns the action item to update the Directory Structure Specification? Is this assigned to @shizhMSFT? Thinking @dtzar, @FeynmanZhou, @iamsamirzon might be able to clarify the security/usability a bit first?