Open Fribur opened 10 months ago
I can't reproduce that. On standard setup (user account + UAC rights) profile folder opens just fine both when frontend runs as user and after elevation.
Interesting. I got Windows 11 Home on the machine I tested this. What windows version do you have? What is your UAC setting?
Here evidence of what I write above: error message when I click on "Open Global Dir":
I assume it's the "Roaming" which is for all users, so I can understand why this might be an issue. Would %LOCALAPPDATA% work here?
Windows 11 pro, all default settings.
Fun thing is my UAC default is 1 notch lower and I've never touched that:
EDIT: bringing that all the way up still does not result in errors.
I assume it's the "Roaming" which is for all users, so I can understand why this might be an issue. Would %LOCALAPPDATA% work here?
Just tried, does not work either. The explorer process simply has no access to the admin user root folder (so localappdata/documents/etc makes no difference):
Funny enough, when I modify "NavigateToDirectory" such that it does not launch the explorer process at a given directory but instead just opens a file at that very same directory: no problem. So UEVRfrontend can do whatever it wants in the admin folder, but it cannot inherit those rights to the explorer process. At least not on Windows Home apparently.
@Fribur since I can't reproduce could you check if replacing NavigateToDirectory
with the following works?
private void NavigateToDirectory(string directory) {
Process.Start(new ProcessStartInfo {
FileName = directory,
UseShellExecute = true
});
}
According to the documentation this delegates opening the folder to Windows UI, same like pressing Win+R and pasting path there.
I tried to play around with all these options as well, does not work. Here a couple of things I tried (what you propose is first option) and result (note: UEVR frontend was in all cases launched from "StandardUserAccount" elevated as "Admin")
private void NavigateToDirectory(string directory)
{
//the following opens explorer window C:\User\StandardUserAccount\Roaming\UnrealVRMod\
Process.Start(new ProcessStartInfo
{
FileName = directory,
UseShellExecute = true
});
//the following opens "test.bat" located in C:\User\AdminAcount\Roaming\UnrealVRMod\ via notepad.exe,
Process.Start(new ProcessStartInfo
{
FileName = "notepad.exe",
Arguments = directory + "\\" + "test.bat",
});
//the following excutes "test.bat" located in C:\User\AdminAcount\Roaming\UnrealVRMod\,
Process.Start(new ProcessStartInfo
{
FileName = directory + "\\" + "test.bat",
});
}
//the following opens explorer window C:\User\StandardUserAccount\Roaming\UnrealVRMod\
it's working then. At least on my system profile directory is located in base user profile. UEVR will go looking for profiles there regardless of elevation.
Also I wonder how you have C:\User\AdminAcount\Roaming\
? At least in my setup elevating the process to admin rights does not create separate folder structure. Profile is still taken from the user that asked for elevation.
Are you sure you mean UAC elevation not creating separate admin account and calling 'runAs'? If the latter then that's not a standard setup and is highly unusual in all versions of Windows that came after UAC was introduced.
And this just fails with the access denied error posted above. Note how it is virtually identical to the notepad.exe
option above. Notepad works, explorer not. Something in Windows (Home?) is just fighting against it. Obviously for security reasons I read somewhere.
//the following fails "access denied",
Process.Start(new ProcessStartInfo
{
FileName = "explorer.exe",
Arguments = directory,
});
it's working then. At least on my system profile directory is located in base user profile. UEVR will go looking for profiles there regardless of elevation.
If that is the intended behavior, then YES, it works indeed :-)
Also I wonder how you have
C:\User\AdminAcount\Roaming\
? At least in my setup elevating the process to admin rights does not create separate folder structure. Profile is still taken from the user that asked for elevation.
What do you see when you add this and place a breakpoint there (Visual Studio/started as "Run as Administrator"= right click on the executable/link (not" "runas"):
var userName = Environment.UserName;
string folder = Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData);
This is what I see:
From a standard user account,
explorer.exe
cannot be started as admin since a couple of windows version. Simple test (from a standard user account)"cmd.exe --> runas /user:*add_admin_user_here* explorer.exe"
. OrWin-Key+R --> explorer.exe --> CTRL+Shift+Enter
(in this case a password will be prompted, but explorer process does not start under admin account).Therefore for a standard user, the call
"Process.Start(explorerPath, "\"" + directory + "\"")
; in NavigateToDirectory will always fail with "Access denied" (that the calling process has admin rights is irrelevant). Interestingly enough files inside filesEnvironment.GetFolderPath(Environment.SpecialFolder.ApplicationData)
can be opened individually without any restrictions/problems, with the rights of the elevated process, but opening the whole folder via explorer.exe does not work. Therefore I would suggest to just remove this functionality of opening an explorer folder at the config file location. I do not expect the average population to work from admin accounts for security reasons. And import/export of individual zip files would still work without opening the whole folder.That aside, the function could be simplified as
explorer.exe
will always be foundAlternatively: one could think about just having the process scanning/injection done by an additional elevated process , and the rest of the application works as logged in standard user?