Skip to content
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

Annotation on a DSC Resource regarding elevation requirements #316

Closed
denelon opened this issue Feb 14, 2024 · 3 comments
Closed

Annotation on a DSC Resource regarding elevation requirements #316

denelon opened this issue Feb 14, 2024 · 3 comments
Labels
Issue-Enhancement The issue is a feature or idea Partner-WinGet Resolution-Fixed The issue is fixed

Comments

@denelon
Copy link
Collaborator

denelon commented Feb 14, 2024

Summary of the new feature / enhancement

I would like to be able to "inspect" a DSC resource and have it provide information regarding elevation requirements.

WinGet package manifests have a concept of "elevationRequired", "elevationProhibited", and "elevatesSelf".

This kind of annotation or property would help orchestrators or commands calling resources understand based on the context they are being called in (system, user, elevated user) to know if the resource should work or fail before calling them.

It would also help when building tooling to generate a configuration file to appropriately decorate the configuration file as to the elevation requirements for those resources.

Proposed technical implementation details (optional)

No response

@denelon denelon added Issue-Enhancement The issue is a feature or idea Partner-WinGet labels Feb 14, 2024
@denelon
Copy link
Collaborator Author

denelon commented Feb 14, 2024

Ideally, this would be supported for both DSC v2 PowerShell Class based resources and DSC v3 resources.

@michaeltlombardi
Copy link
Collaborator

A few approaches spring to mind for DSCv3 resources, all in the resource manifest:

  1. Add an elevation property to the top-level of the manifest, with the enum values default, prohibited, required, and self - the expectation here is that the resource executes according to this setting, regardless of the operation. So if a resource is defined with "elevation": "required", it must be run elevated for get, test, and set operations. If the property isn't specified, the resource is interpreted as having a value of default.
  2. Add the same property to the command/operation sections of the manifest. In this case, the property applies only to that operation. Setting elevation for set has no effect on whether elevation is required or prohibited for get.

I think it would be possible to support both, but only one in a manifest - if the top-level elevation is set it should be prohibited in the operation properties and vice versa.

I don't see a way to do this for existing PSDSC resources, short of introducing a new attribute (like DscElevation()) or a not-required method, like GetElevationInfo(). It can't be worked backwards into the existing DscResource() attribute as far as I know.

@SteveL-MSFT
Copy link
Member

Fixed via #351

@SteveL-MSFT SteveL-MSFT added the Resolution-Fixed The issue is fixed label Mar 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Issue-Enhancement The issue is a feature or idea Partner-WinGet Resolution-Fixed The issue is fixed
Projects
None yet
Development

No branches or pull requests

3 participants