Implement RunAsGroup Resource about dsc HOT 11 OPEN

@mgreenegit and I discussed this, we propose a single property called SecurityContext with an enumeration with the values Current,Elevated, and Restricted as allowed values currently. On non-Windows, Elevated would be root and Restricted would be non-root. For the behavior in the results of being invoked, the proposal from @JohnMcPMS makes sense.

from dsc.

Can we reference a secret by vault/name? Then let secretmanagement sort out the underlying store.

from dsc.

This should allow for configuration that needs some aspects running elevated vs other parts that do not. Alternatively if the user is root/elevated, it should also allow running as non-elevated.

from dsc.

We've had a few different scenarios to look at on the WinGet configuration side of the world.

We want to be able to run individual resources either in the user context or elevated as necessary for package installation and other use cases. This logically can be thought of as having a need for both an "elevated" execution process and a "non-elevated" execution process to handle a single configuration file.

For example, if I want to install Visual Studio and then configure workloads or extensions, the execution must be elevated. If that same configuration needs to install a package in the user scope running the resource elevated could cause undesired results.

Note: many packages determine their install scope based on whether the installer was run elevated or not.

from dsc.

For WinGet scenario, we can defer RunAs different creds, but have a resource group to run either as elevated or non-elevated. Of course, requiring elevation will fail if the user is not elevated (not bring up UAC on Windows or sudo prompt on non-Windows).

This means this resource will have a single boolean property called RequireElevated.

from dsc.

This means this resource will have a single boolean property called RequireElevated.

Is it possible to make a decision on the name and property for this so that we can be aligned? There is a desire for us to also have this for v2 (PowerShell only) configurations that we already support, and it would be great to have a single resource definition and documentation that worked across both.

I would prefer that we use an enumeration as it enables better self-documentation. The opposite of RequireElevated in English could be interpreted as "don't require elevated", meaning that any context is acceptable. In reality, I think we need "require not elevated", as the default state is already context agnostic so one would just not use the group. My suggestion would be that the property be named ElevationContext and the values be:

Additional values could be supported in the future, such as SYSTEM to indicate a requirement to run as such.

My expectation is that the result of be invoked in:

1. The correct context: the contained fragment is run as is
2. A higher context: the contained fragment is invoked in the lower context
3. A lower context: an error is produced

In this way, the caller is responsible for invoking from the highest required context and the group is responsible for downgrading as necessary (and never upgrading).

from dsc.

Thanks, looks great. What would be the "module" / resource name? The title of the issue seems to have the resource name as RunAsGroup, but what is the "module" going to be (sorry, not sure what term you are using for the "group of resources" here).

from dsc.

Thanks, looks great. What would be the "module" / resource name? The title of the issue seems to have the resource name as RunAsGroup, but what is the "module" going to be (sorry, not sure what term you are using for the "group of resources" here).

This resource will be implemented as part of dsc.exe so wouldn't be part of a module. The reason for this is that the properties of this resource would itself be a config which dsc.exe knows how to handle.

from dsc.

Sorry, the better question is "How should it be referenced?" Is it to be called DSC/RunAsGroup?

from dsc.

Sorry, the better question is "How should it be referenced?" Is it to be called DSC/RunAsGroup?

Ah, yes, it'll be called that. In DSCv3 terminology, that's the resource type name.

from dsc.

Since we have metadata now to indicate if the whole config requires elevated or not, we can defer this until actual scenario requires it

from dsc.