Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add UIAccess flag to allow managing admin windows without running as admin #538

Open
eugenesvk opened this issue May 19, 2024 · 10 comments
Open

Comments

@eugenesvk
Copy link

There is a simpler way to manage other admin windows without becoming an admin app yourself (and doing admin task scheduler stuff), thus reducing the risk associated with admin

AutoHotkey does it to allow rebinding hotkeys in admin windows:

  • you add a manifest to your exe in a specific format with uiaccess flag (disabled)
  • use AutoHotkey and it's EnableUIAccess script to self-sign AltSnap (without this uiaccess doesn't work)
  • (same script also) turns the uiaccess flag on
  • relocate it to Program Files (also required)

Then AltSnap will be able to run without being admin, yet control other apps even admin

You could add it as part of the installation as AHK does it or just make the users do it manually

You could also sign your binary yourself to avoid this trouble, but then as far as I know there are no free certificates to allow open source devs do that

@RamonUnch
Copy link
Owner

I am not shure this is a good Idea, I like AltSnap not to interact with anything elevated, with this flag, assuming iI can make it work it would mean that as soon as a user install in Program files it would be forced on, which I do not like.

So this would force to have an extra version. Plus I am not really willing to invest time and mony in purchasing a signing certificate.

Maybe someone else can do it, but I am not sure of the value. Yes it would reduce surface-area for when you do wand to move elevated windows but it would increase the odds of for people on which the behavior would be forced.

If there was a way to decide at runtime this UIAcess without forcing it into the .manifest then would make it optional, but the whole process as it is, is not appealing to me.

I am not sure I fully understand what you sait though, You mean AHK can apply the flag to another progra and it works? If so I could just add the procedure to a txt file for the interested users to apply.

@eugenesvk
Copy link
Author

It won't be forced, that depends entirely on your installation options. For example, AutoHotkey can be installed/launched in either variants and you can change it by launching it's installer and changing a tick mark in options. So it's strictly a benefit over the current situation where if you want to interact you have to elevate

If there was a way to decide at runtime

there is, just like currently you're relaunching your app elevated you'd relaunch the UIA-enabled variant of the app

You mean AHK can apply the flag to another progra and it works? If so I could just add the procedure to a txt file for the interested users to apply.

Yes, but only if the app already has a manifest added. The script signs the binary with a self-signed certificate, and toggles the UIA flag in the manifest

The instructions for another app are here and the example manifest that needs to be embedded is here

The only thing this is missing is the dynamic part of easily changing the variant from a context menu, that would need support from your app/installer to have a menu "relaunch AltSnap with UIA" and "relaunch AltSnap without UIA"

@RamonUnch
Copy link
Owner

there isalready manifest file in altsnap.exe for the usual stuff so it should work after ahk script.

@eugenesvk
Copy link
Author

eugenesvk commented May 19, 2024

Unfortunately it doesn't since it has some formatting difference, the app doesn't launch after being edited by the script, I guess since AHK script is meant to sign AHK it wasn't made to generally work with any manifest

Think you could either update the manifest to whatever format that script expects or disable the manifest changing part of the script, distribute two binaries with two manifests (with UIAccess flag dis/enabled) and then use the script to just generate self-signed certificates/sing the UIA binary using that certificate

Or maybe there is an better solution, I just only know this one

@RamonUnch
Copy link
Owner

When reading the ahk script it seems it is expecting the property to be present (but disabled)
https://github.com/Milly/AutoHotKey-scripts/blob/master/EnableUIAccess/EnableUIAccess.ahk

So here is a version of AltSnap.exe (x64) with this modified manifest file with the UIAccess=false, try the ahk script, (I dont have AHK2 installed actually).

AltSnap1.63test4_x64.zip

@eugenesvk
Copy link
Author

In this binary I can't even parse the the manifest with the win tool, get

MT.EXE : general error c101008c: Failed to read the manifest from the resource of file "D:\Downloads\AltSnap1.63test4_x64\AltSnap.exe". Windows was unable to parse the requested XML data.

AHK also fails, though I'm using the script I linked above since don't have AHK1 that's needed for the ancient version you linked

@RamonUnch
Copy link
Owner

What about this one?
AltSnap.zip

@eugenesvk
Copy link
Author

this seems to work

@RamonUnch
Copy link
Owner

Ok, I will see later what to do, for now AltSnap needs to be modified in order to work in the Program Files directory #539.

This was referenced May 25, 2024
@RamonUnch
Copy link
Owner

Here is the latest test version of altsnap that supports being installed for multiple users.

AltSnap1.64test1_x64.zip

If no .ini file is present in its directory it will look for %APPDATA%\AltSnap\AltSnap.ini If there is no ini file it ill try to copy a default ini named "\AltSnap.dni".

So for the portable mode you just put the AltSnap.ini next to AltSnap.exe for multi-user mode you must rename the .ini file to .dni and you are set. Each user will be able to have its own congif.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants