Implement RunAsGroup Resource

[SteveL-MSFT]

Summary of the new feature / enhancement

This GroupResource runs every resource within its config fragment under specified credentials. Need to determine if username/password is the right model and how it should be passed securely within the Config (via a variable?)

Proposed technical implementation details (optional)

No response

[mgreenegit]

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

[SteveL-MSFT]

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.

[denelon]

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.

[SteveL-MSFT]

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.

[JohnMcPMS]

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:

Value	Description
Any	This value indicates that the group needs not do anything, as any context is acceptable.
Elevated	This value indicates that the group must be run with a token that is a member of the Administrators group on Windows. This same value could be used to indicate higher privileges on other operating systems.
Restricted	This value indicates that the group should be run as a restricted version of the current user. On Windows, this would be the lowest privilege level available to the user on the current user session. Thus, the medium IL token if UAC is enabled, or the only token if UAC is disabled.

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).

[SteveL-MSFT]

@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.

[JohnMcPMS]

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).

[SteveL-MSFT]

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.

[JohnMcPMS]

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

[SteveL-MSFT]

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.

[SteveL-MSFT]

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