win_service failing with permission issue in ansible 2.10.2 (works in 2.9.9) #118
Comments
|
I have a similar issue. Test playbook: Ansible 2.9.11 results: Ansible 2.10.3 with ansible.windows 1.2.0 results: EDIT: Adding results for ScDeviceEnum Test playbook: Ansible 2.9.11 results: Ansible 2.10.3 with ansible.windows 1.2.0 results: Let me know if I can provide additional information. |
|
Thanks for the report, the module went through a massive rewrite in 2.10 and it looks like we are requesting some permissions we may not actually need for the task at hand. Currently when we open a handle to the service we request the AllAccess rights which seems to be unavailable for certain services. We will need to fix up the code to be a bit more flexible in this regard as clearly we could achieve the same this with lesser permission in 2.9 and earlier. |
|
The PR #149 uses a restricted set of privileged when opening a service. When testing with some of the examples shared here the changes fix the problems reported. |
|
I confirm that with that patch my test playbook works fine with |
|
Thanks for testing it out, would you be able to run the following and share your output: # https://docs.microsoft.com/en-us/windows/win32/services/service-security-and-access-rights
Add-Type -TypeDefinition @'
using System;
namespace SCManager
{
[Flags]
public enum AccessMask
{
UNKNOWN = 0x00000000,
SERVICE_ALL_ACCESS = 0x000F01FF,
SERVICE_CHANGE_CONFIG = 0x00000002,
SERVICE_ENUMERATE_DEPENDENTS = 0x00000008,
SERVICE_INTERROGATE = 0x00000080,
SERVICE_PAUSE_CONTINUE = 0x00000040,
SERVICE_QUERY_CONFIG = 0x00000001,
SERVICE_QUERY_STATUS = 0x00000004,
SERVICE_START = 0x00000010,
SERVICE_STOP = 0x00000020,
SERVICE_USER_DEFINED_CONTROL = 0x00000100,
ACCESS_SYSTEM_SECURITY = 0x01000000,
DELETE = 0x00010000,
READ_CONTROL = 0x00020000,
WRITE_DAC = 0x00040000,
WRITE_OWNER = 0x00080000,
STANDARD_RIGHTS_REQUIRED = 0x000F0000,
STANDARD_RIGHTS_READ = 0x00020000,
STANDARD_RIGHTS_WRITE = 0x00020000,
STANDARD_RIGHTS_EXECUTE = 0x00020000,
GENERIC_READ = STANDARD_RIGHTS_READ |
SERVICE_QUERY_CONFIG |
SERVICE_QUERY_STATUS |
SERVICE_INTERROGATE |
SERVICE_ENUMERATE_DEPENDENTS,
GENERIC_WRITE = STANDARD_RIGHTS_WRITE |
SERVICE_CHANGE_CONFIG,
GENERIC_EXECUTE = STANDARD_RIGHTS_EXECUTE |
SERVICE_START |
SERVICE_STOP |
SERVICE_PAUSE_CONTINUE |
SERVICE_USER_DEFINED_CONTROL,
}
}
'@
Function Get-ServiceAcl {
[CmdletBinding()]
param (
[Parameter(Mandatory=$true)]
[String]
$Name
)
$sddl = ((sc.exe sdshow $Name) -join "").Trim()
$sd = ConvertFrom-SddlString -Sddl $sddl
$sd.RawDescriptor.DiscretionaryAcl | ForEach-Object {
$sid = $_.SecurityIdentifier
try {
$account = $sid.Translate([Security.Principal.NTAccount])
} catch [Security.Principal.IdentityNotMappedException] {
$account = $sid
}
try {
$access = [SCManager.AccessMask]$_.AccessMask
} catch [Management.Automation.PSInvalidCastException] {
$access = [SCManager.AccessMask]::UNKNOWN
}
[PSCustomObject]@{
Account = $account
Access = $access
AccessMask = '0x{0:X8}' -f $_.AccessMask
AceType = $_.AceType
}
}
}
Get-ServiceAcl -Name SepMasterService | Format-ListThis will get the SDDL of the service and convert it to a human readable output of the DACL of the service. If that fails in any way then Just to confirm you are trying to just get the info from the service right? The default rights for |
|
Sure, here you go: From administrative and normal command prompt (no difference): From administrative cmd prompt: From 'normal' command prompt: I am running the test playbook listed above: |
|
Thanks for the confirmation, looking like the Another alternative that will work for you today is to use win_service_info which is designed to get the stats on a service and not make any changes. |
|
OK, thanks. I agree that Indeed, I guess it is 'normal' that an endpoint protection service (SepMasterService refers to the Symantec Endpoint Protection client) can indeed not easily be changed. Perhaps it would be a good idea to translate this into a more user friendly error? In hindsight the information is there ("Access denied"), but I did not understand it. And/or an additional explanation in the |
|
The current problem is an issue because we are requesting more rights than we actually need so we can fix that bug. The issue with your
I'm not sure how much more user friendly we could make the error message. If it's saying access is denied then it means exactly that, you don't have the rights to access/modify the service. You wouldn't document that you need delete permissions to delete a file as it's just something that is just implicit knowledge. Also documenting how to view the existing rights is unfortunately not that simple. The code I gave you is not really something we can easily add into an example and is really information that most people don't need to know about. |
OK, I indeed do not have a suggestion to make this better, and agree the current error contains the necessary info. Thanks for the help! |
|
I was having a look at the module and based on how it is structured it's really difficult to determine if the For your particular use case I would recommend using |
SUMMARY
I have a simple task that runs through a list of windows services and disables them. It was working in ansible 2.9.9 without any issue, but in ansible 2.10.2 it is failing on two of the services with the following error:
Task:
Error for the "RmSvc" service:
Error for the "ScDeviceEnum" service:
All the other services are disabled without issue.
If I roll back to ansible 2.9.9, it works as expected.
ISSUE TYPE
COMPONENT NAME
win_service
ANSIBLE VERSION
CONFIGURATION
OS / ENVIRONMENT
Tested targeted Windows 2016 and Windows 2019, problem occurs on both.
STEPS TO REPRODUCE
Run the example task below against a basic windows 2016 or windows 2019 server.
It will fail on the services "RmSvc" and "ScDeviceEnum".
EXPECTED RESULTS
Expect all services to be disabled without error.
ACTUAL RESULTS
Errors on services "RmSvc" and "SvDeviceEnum".
The text was updated successfully, but these errors were encountered: