Set ADMIN command not elevating

I'm having trouble with "Set ADMIN=toggle" command, It's a built-in button. When I click it, it asks for how long and I specify 10 minutes and proceed, then hit Yes on the UAC prompt.

It then shows "Administrator: " in the title bar, if I launch a command prompt from the lister at this point, that program starts as Administrator.

The issue is that I am still not able to access certain directories that I would normally be able to do as Administrator. In fact if I go there, it asks if I want to elevate again, after which is tells me access is denied.

If I, instead, exit Directory Opus (12.20 x64), and launch the entire program as administrator, I can access the directory in question without any problem.

Lastly, I use a task manager replacement called "Process Hacker" which among other things lets me see the Elevation status of a process. dopus.exe never changes from 'Limited.' throughout this whole time. Perhaps it's just a thread that is getting elevated.

In any case, I should be able to read the directory. BUILTIN\Administrators has RX access to the directory according to icacls. The directory I'm trying to move into is "C:\Program Files\WindowsApps"

Dopus.exe itself won't become elevated when the button is pushed; instead, actions are proxied through a separate elevated process.

Admin mode doesn't affect folder reading, only write operations. Admin mode is for things like the main Program Files folder where anyone can read it but you need elevation to make changes.

A way to access folders you can't read without elevation is something I've been thinking about for a while, mainly for that very same WindowsApps folder and the inexplicable way Microsoft have permissioned it. At the moment, you'll need to relaunch the whole process as admin to read that folder, but note that that will cause problems with Explorer Replacement, since then the rest of the desktop can't talk to dopus.exe to ask it to open a folder.

(As an aside, the way they locked down that folder so much broke the backup system that's built into Windows for over a year, as it couldn't cope with it when restoring a backup made by the OS itself. It is quite ridiculous.)

You can usually access the folders for individual apps under that folder; it's just the top-level folder you can't read. So if you just need to look in a particular app's folder below WindowsApps, you can do that by going there directly. I usually find the app path via an elevated command prompt.

1 Like

Thanks, glad to know that it wasn't something I was doing wrong. All of the aforementioned workaround are what I've used already.

I'm not an in-depth Windows developer, but do threads have their own access tokens? Is it possible to elevate a listers thread to administrator?

Is it possible to have an elevated lister have all file operations go through the proxy?

Thanks again!

Only processes can elevate, but a thread can use another process as a proxy, if it's programmed to work that way. There's no way for you to make this happen as a user, though, unless a program has been written to make it possible.

Admin Mode listers already use a proxy admin process to do write operations, but there isn't currently a way to make them use the same thing for all read and folder-listing operations. It's something we're thinking about (although we haven't go to the stage of doing writing anything for it, so it's probably a while off).

Most folders in Windows that you'd want to look at allow anyone to read them but sometimes restrict who can write to them. The WindowsApps one is an unusual case (and for no sane reason I can fathom, but what can you do about Microsoft's strange ideas...).

1 Like