How to check for UIAccess reliably

[gexgd0419]

When UAC is disabled, using GetTokenInformation to check whether the process token has UIAccess will incorrectly return false, even if the process can pass other tests for UIAccess. This makes NVDA disable touch gestures and audio ducking when UAC is disabled, even though the system allows NVDA to do so in this case. Related issues:

• UAC breaks touch interaction. #13591
• Audio ducking not working when UAC is at 0% #15790

UIAccess, admin rights, and a high integrity level are different things. If you are an admin and run NVDA with UIAccess, it will have UIAccess and a high integrity level, but not with admin rights, so it can interact with admin windows, but cannot modify system files. And it turns out that the UIAccess flag in the process token and the actual UIAccess rights are also different.

Audio ducking

Audio ducking performs user-mode checks, and a process can pass the test if any of the following is true:

• The process token has an integrity level of high, or higher.
• The process token has the UIAccess flag set.

So audio ducking also checks only the process token like our code does, instead of checking the "real" UIAccess rights. This causes the following:

• If a process is run as administrator, it will have admin rights and a high integrity level, so it can use audio ducking (or any feature provided by AccSetRunningUtilityState), regardless of the UIAccess rights.
• If a process is run as a non-admin user, it will have a medium integrity level. If the UAC is also disabled, the UIAccess flag in the process token won't be set, so the process cannot use audio ducking even if it actually has UIAccess rights.

Touch gestures

Touch gestures, or the RegisterPointerInputTarget function, also requires UIAccess. However, this function goes into kernel-mode to check the real UIAccess rights.

In addition to RegisterPointerInputTarget, NVDA's touch handler code also uses AccSetRunningUtilityState, so it will be affected by the logic used by audio ducking as well.

Furthermore, it seems that when UAC is disabled, the system will no longer check the program's digital signature or location. It will be granted UIAccess if its manifest asks for that.

Behavior comparison tables

Following are tables showing the result of different operations when UAC is enabled/disabled, when logged in as an admin/normal user, and when with/without UIAccess.

When UAC is enabled

Item	Admin, UIAccess	Admin, no UIAccess	Non-admin, UIAccess	Non-admin, no UIAccess
Super topmost	Yes	No	Yes	No
Token UIAccess flag	Yes	No	Yes	No
Token integrity level	High	High	Medium plus	Medium
AccSetRunningUtilityState	Succeed	Succeed	Succeed	Fail
RegisterPointerInputTarget	Succeed	Fail	Succeed	Fail

When UAC is disabled

Item	Admin, UIAccess	Admin, no UIAccess	Non-admin, UIAccess	Non-admin, no UIAccess
Super topmost	Yes	No	Yes	No
Token UIAccess flag	No	No	No	No
Token integrity level	High	High	Medium	Medium
AccSetRunningUtilityState	Succeed	Succeed	Fail	Fail
RegisterPointerInputTarget	Succeed	Succeed	Succeed	Succeed

Possible ways to detect UIAccess

As shown above, different system components may use different rules when checking for UIAccess rights, even if they just have "requires UIAccess" in their documentation.

As the usual way of checking the process token does not work when UAC is disabled, we might choose some other way as a fallback.

Here are the ways I came up with.

• As NVDA uses different executables for UIAccess and non-UIAccess, we can check what executable the code is running in. If the UAC is disabled, the current copy is an installed copy, and the current executable has UIAccess in its manifest, then it should have UIAccess.
• Call RegisterPointerInputTarget, but with an invalid input type, for example, PT_POINTER. This way, the function always fails, and the input target is not actually set. However, we can then check the error code. If it failed with ERROR_ACCESS_DENIED, then it doesn't have UIAccess; if it failed with ERROR_INVALID_PARAMETER, then it has UIAccess.
• Topmost window of a UIAccess process will be "super-topmost", on top of other topmost windows such as task manager. We may be able to check its Z-order, or use undocumented functions such as GetWindowBand to get its band.

Which way is better? Or do you have better ways?

cc. @SaschaCowley @seanbudd @michaelDCurran @CyrilleB79 @LeonarddeR

[seanbudd]

Thanks for your thorough investigation here - sorry we don't have any suggestions at this point