-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Description
Description of the new feature / enhancement
I tried to write a configuration file that updates a registry key. It failed at first run, because my PowerShell inside VS code isn't elevated, which the error told me. When running it again in an elevated shell, everything was fine.
Looking for solutions on how to place that requirement in the assertions
section of the configuration I didn't find any specific DSC resource to accomplish this. Only a DscResource.Common
function called Assert-ElevatedUser
.
After thinking about putting that in a Script resource, I realized that it isn't really a state of the system itself, but only the current runtime/process. Thus, it would be better suited as an additional property inside the configuration file instead of a resource.
Proposed technical implementation details
Add a new boolean property in the configuration dsc schema below properties
called something like requiresElevation
, that would be optional with a default of false
.
winget configure
would then check for elevation if that property is true
. If that is not the case it could either fail with an appropriate error message or restart the process as an elevated user, triggering the usual UAC prompt in Windows.
Further improvements could range from adding the property to individual resources and only running them in elevated mode or extending the property from a boolean to an array of privileges required to apply the configuration, though I'm not too deep into Windows administration to know if that is feasible or useful.