New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add metadata in config to indicate a config requires admin, non-admin, system #258
Comments
WinGet package manifests have: Something similar for a DSC Resource would mean errors caused by mismatched elevation requirements could be caught before execution. |
A consistent request from our customers is to have a single configuration document that can be used in multiple contexts to achieve the overall desired configuration. On Windows, this means the ability to group the configuration elements to run under the My understanding of the requirements on any such group to provide this behavior are thus:
My expectation on the average use case would be: resources:
- name: SYSTEM group
type: DSC/UserContextGroup
properties:
UserContext: SYSTEM
WrongContextAction: Ignore
resources:
...
- name: User group
type: DSC/UserContextGroup
properties:
UserContext: User
WrongContextAction: Ignore
resources:
- name: Restricted user group
type: DSC/UserContextGroup
properties:
UserContext: RestrictedUser
WrongContextAction: Switch
resources:
...
- name: Unrestricted user group
type: DSC/UserContextGroup
properties:
UserContext: UnrestrictedUser
WrongContextAction: Switch
resources:
... With the goal of providing two effectively independent configuration documents via the |
For now, we'll implement #54 to handle elevation/non-elevation, but anything more, we recommend WinGet team to implement this group resource. |
For the "fail-fast" case where a config doesn't have mixed context, we should also standardize on meta-data in the configuration similar to #253 (comment): metadata:
Microsoft.DSC:
RequiredSecurityContext: Elevated Same enum values as #54 |
Summary of the new feature / enhancement
Some configurations may require admin or may require user to not be admin to apply. The actual configuration can use an AssertionGroup to a resource that checks if user is elevated/root. However, it might make sense to also have this info in the
metadata
property of the configuration, but this would just be documentation.Proposed technical implementation details (optional)
The text was updated successfully, but these errors were encountered: