When running As Administrator write to some files fails with access is denied error #16296

@237dmitry commented on GitHub (Dec 28, 2021):

@237dmitry commented on GitHub (Dec 28, 2021): ![11](https://user-images.githubusercontent.com/78153320/147572356-6384d277-8210-42f4-a25a-2959eea24069.png)

claunia commented

@yudindm commented on GitHub (Dec 28, 2021):

It doesn`t work for me in Windows Terminal.

@yudindm commented on GitHub (Dec 28, 2021): It doesn`t work for me in Windows Terminal. ![image](https://user-images.githubusercontent.com/8970838/147573161-f19a8fd7-734f-434c-9278-b38749a5ffbf.png)

claunia commented

@elsaco commented on GitHub (Dec 28, 2021):

@yudindm there is no security shield displayed in your terminal when running as admin. Usually there's an icon in upper left corner indicating this is an elevated session. Did you disable it? Couldn't replicate your issue on my system:

@elsaco commented on GitHub (Dec 28, 2021): @yudindm there is no security shield displayed in your terminal when running as admin. Usually there's an icon in upper left corner indicating this is an elevated session. Did you disable it? Couldn't replicate your issue on my system: ![hosts_append_test](https://user-images.githubusercontent.com/3933920/147584661-c9538cd0-ae0b-4238-b942-ed8375cf6f0c.png)

claunia commented

@eryksun commented on GitHub (Dec 28, 2021):

There's no UAC shield if UAC is disabled by setting "EnableLUA" to 0 in "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System", but in that case an admin should have full access to the "hosts" file.

@yudindm, check the available and enabled groups via whoami.exe /groups to ensure that the administrators group (S-1-5-32-544) is present and enabled for granting access. It should be, else PowerShell shouldn't be displaying "Administrator: " in the session title.

@eryksun commented on GitHub (Dec 28, 2021): There's no UAC shield if UAC is disabled by setting "EnableLUA" to 0 in "HKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System", but in that case an admin should have full access to the "hosts" file. @yudindm, check the available and enabled groups via `whoami.exe /groups` to ensure that the administrators group (S-1-5-32-544) is present and enabled for granting access. It should be, else PowerShell shouldn't be displaying "Administrator: " in the session title.

claunia commented

@237dmitry commented on GitHub (Dec 28, 2021):

There's no UAC shield if UAC is disabled by setting "EnableLUA" to 0

This is not quite true. Elevated rights with the help of third-party utilities can be obtained for one tab, while the terminal itself remains as before and remains without the shield icon, but the title of an elevated tab has "Administrator: " prefix.

@237dmitry commented on GitHub (Dec 28, 2021): > There's no UAC shield if UAC is disabled by setting "EnableLUA" to 0 This is not quite true. Elevated rights with the help of third-party utilities can be obtained for one tab, while the terminal itself remains as before and remains without the shield icon, but the title of an elevated tab has "Administrator: " prefix. ![gsudo](https://user-images.githubusercontent.com/78153320/147592045-497dc1e1-a8f9-40cf-85ba-54943c2796ab.png)

claunia commented

@eryksun commented on GitHub (Dec 28, 2021):

This is not quite true. Elevated rights with the help of third-party utilities can be obtained for one tab, while the terminal itself remains as before and remains without the shield icon, but the title of an elevated tab has "Administrator: " prefix.

Maybe you read too much into my statement. Your point doesn't make what I said "not quite true". I didn't say that disabling UAC was the only way that the UAC shield might be missing even though the terminal or a tab has administrator access. Your point is generally interesting, but it isn't relevant here because the issue states "Start Windows Terminal As Administrator".

@eryksun commented on GitHub (Dec 28, 2021): > This is not quite true. Elevated rights with the help of third-party utilities can be obtained for one tab, while the terminal itself remains as before and remains without the shield icon, but the title of an elevated tab has "Administrator: " prefix. Maybe you read too much into my statement. Your point doesn't make what I said "not quite true". I didn't say that disabling UAC was the only way that the UAC shield might be missing even though the terminal or a tab has administrator access. Your point is generally interesting, but it isn't relevant here because the issue states "Start Windows Terminal As Administrator".

claunia commented

@237dmitry commented on GitHub (Dec 28, 2021):

because the issue states "Start Windows Terminal As Administrator"

Ok

@237dmitry commented on GitHub (Dec 28, 2021): > because the issue states "Start Windows Terminal As Administrator" Ok

claunia commented

@zadjii-msft commented on GitHub (Jan 3, 2022):

Also, the shield icon was only added in 1.12, so it's totally reasonable that it's not present for OP on a 1.11 build.

If I run the same command but in pwsh without Windows Terminal it completes successfully.

That's the bit that confuses me here - the only thing that would be different about these scenarios is the Terminal running with package identity, in addition to being elevated. But that shouldn't affect the ability to write that file... especially since it Works On My Machine^tm.

@zadjii-msft commented on GitHub (Jan 3, 2022): Also, the shield icon was only added in 1.12, so it's totally reasonable that it's not present for OP on a 1.11 build. > If I run the same command but in pwsh without Windows Terminal it completes successfully. That's the bit that confuses me here - the only thing that would be different about these scenarios is the Terminal running with package identity, in addition to being elevated. But that _shouldn't_ affect the ability to write that file... especially since it Works On My Machine<sup>tm</sup>.

claunia commented

@yudindm commented on GitHub (Jan 5, 2022):

@eryksun

There's no UAC shield if UAC is disabled by setting "EnableLUA" to 0 in "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System", but in that case an admin should have full access to the "hosts" file.

PS C:\Users\yudindm> (Get-ItemProperty HKLM:SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System).EnableLUA
1

check the available and enabled groups via whoami.exe /groups to ensure that the administrators group (S-1-5-32-544) is present and enabled for granting access

I'm using Russian Windows edition and to prevent localized output here I'm using commands that don't have localized output

PS C:\Users\yudindm> ([Security.Principal.WindowsIdentity]::GetCurrent()).Claims | ?{ $_.Value -eq 'S-1-5-32-544' }

Issuer         : AD AUTHORITY
OriginalIssuer : AD AUTHORITY
Properties     : {[http://schemas.microsoft.com/ws/2008/06/identity/claims/windowssubauthority, NTAuthority]}
Subject        : System.Security.Principal.WindowsIdentity
Type           : http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid
Value          : S-1-5-32-544
ValueType      : http://www.w3.org/2001/XMLSchema#string


PS C:\Users\yudindm> $currentPrincipal = New-Object Security.Principal.WindowsPrincipal([Security.Principal.WindowsIdentity]::GetCurrent())
PS C:\Users\yudindm> $currentPrincipal.IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)
True

@zadjii-msft

the only thing that would be different about these scenarios is the Terminal running with package identity, in addition to being elevated But that shouldn't affect the ability to write that file... especially since it Works On My Machinetm.

It shurely worked on My Machine also some time ago.
Since then I probaby installed a Windows update or a Windows Terminal update wich broke expected behavior.

@yudindm commented on GitHub (Jan 5, 2022): @eryksun > There's no UAC shield if UAC is disabled by setting "EnableLUA" to 0 in "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System", but in that case an admin should have full access to the "hosts" file. ``` PS C:\Users\yudindm> (Get-ItemProperty HKLM:SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System).EnableLUA 1 ``` > check the available and enabled groups via whoami.exe /groups to ensure that the administrators group (S-1-5-32-544) is present and enabled for granting access ![image](https://user-images.githubusercontent.com/8970838/148177816-ff55e74d-8d91-4bf4-9d8d-5d854ba05cf1.png) I'm using Russian Windows edition and to prevent localized output here I'm using commands that don't have localized output ``` PS C:\Users\yudindm> ([Security.Principal.WindowsIdentity]::GetCurrent()).Claims | ?{ $_.Value -eq 'S-1-5-32-544' } Issuer : AD AUTHORITY OriginalIssuer : AD AUTHORITY Properties : {[http://schemas.microsoft.com/ws/2008/06/identity/claims/windowssubauthority, NTAuthority]} Subject : System.Security.Principal.WindowsIdentity Type : http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid Value : S-1-5-32-544 ValueType : http://www.w3.org/2001/XMLSchema#string PS C:\Users\yudindm> $currentPrincipal = New-Object Security.Principal.WindowsPrincipal([Security.Principal.WindowsIdentity]::GetCurrent()) PS C:\Users\yudindm> $currentPrincipal.IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator) True ``` @zadjii-msft > the only thing that would be different about these scenarios is the Terminal running with package identity, in addition to being elevated But that shouldn't affect the ability to write that file... especially since it Works On My Machinetm. It shurely work**ed** on My Machine also some time ago. Since then I probaby installed a Windows update or a Windows Terminal update wich broke expected behavior.

claunia commented

@eryksun commented on GitHub (Jan 5, 2022):

The administrators group is enabled in the current access token. That should be enough. By default, the "hosts" file doesn't have a mandatory label that restricts write access to high integrity level. To be extra certain, check to make sure the current security context has the high mandatory level group "S-1-16-12288" using whoami.exe /groups or Sysinternals Process Explorer. UAC shouldn't create a token with the administrators group enabled that's not elevated, but weird things happen. (The opposite is possible, i.e. high integrity level without administrator access.) Also check the discretionary and mandatory security of the "hosts" file via icacls.exe "%SystemRoot%\System32\drivers\etc\hosts". The latter includes the mandatory label and policy, if any. I don't know how to inspect the mandatory label in PowerShell.

@eryksun commented on GitHub (Jan 5, 2022): The administrators group is enabled in the current access token. That should be enough. By default, the "hosts" file doesn't have a mandatory label that restricts write access to high integrity level. To be extra certain, check to make sure the current security context has the high mandatory level group "S-1-16-12288" using `whoami.exe /groups` or Sysinternals Process Explorer. UAC shouldn't create a token with the administrators group enabled that's not elevated, but weird things happen. (The opposite is possible, i.e. high integrity level without administrator access.) Also check the discretionary and mandatory security of the "hosts" file via `icacls.exe "%SystemRoot%\System32\drivers\etc\hosts"`. The latter includes the mandatory label and policy, if any. I don't know how to inspect the mandatory label in PowerShell.

claunia commented

@yudindm commented on GitHub (Jan 10, 2022):

@eryksun

high mandatory level group "S-1-16-12288"

Yes. It's present.

Also check the discretionary and mandatory security of the "hosts" file

Because all group names in the output are in Russian below I translated them in English:
NT AUTHORITY\SYSTEM:(I)(F)
BUILTIN\Administrators:(I)(F)
BUILTIN\Users:(I)(RX)
APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(I)(RX)
APPLICATION PACKAGE AUTHORITY\ALL RESTRICTED APPLICATION PACKAGES:(I)(RX)

@yudindm commented on GitHub (Jan 10, 2022): @eryksun > high mandatory level group "S-1-16-12288" Yes. It's present. > Also check the discretionary and mandatory security of the "hosts" file ![image](https://user-images.githubusercontent.com/8970838/148740303-3b4ca5a3-2982-4cfe-b7c1-a90a38e932ff.png) Because all group names in the output are in Russian below I translated them in English: NT AUTHORITY\SYSTEM:(I)(F) BUILTIN\Administrators:(I)(F) BUILTIN\Users:(I)(RX) APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(I)(RX) APPLICATION PACKAGE AUTHORITY\ALL RESTRICTED APPLICATION PACKAGES:(I)(RX)

claunia commented

@eryksun commented on GitHub (Jan 10, 2022):

Everything looks normal. Maybe some entry is a conditional access control entry, which icacls doesn't dupport. SDDL does. Try (get-acl "$env:SystemRoot\System32\drivers\etc\hosts").Sddl.

If you have access to a debugger, such as the WinDbg store app, attach to the affected PowerShell instance and run !token to display the contents of the process access token.

@eryksun commented on GitHub (Jan 10, 2022): Everything looks normal. Maybe some entry is a conditional access control entry, which icacls doesn't dupport. SDDL does. Try `(get-acl "$env:SystemRoot\System32\drivers\etc\hosts").Sddl`. If you have access to a debugger, such as the WinDbg store app, attach to the affected PowerShell instance and run `!token` to display the contents of the process access token.

claunia commented