-
Notifications
You must be signed in to change notification settings - Fork 13
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
NavigateToDirectory cannot work for Standard Users (process having elevated admin rights does not change that) #6
Comments
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. |
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? |
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 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",
});
} |
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 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 //the following fails "access denied",
Process.Start(new ProcessStartInfo
{
FileName = "explorer.exe",
Arguments = directory,
}); |
If that is the intended behavior, then YES, it works indeed :-) |
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"):
|
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?
The text was updated successfully, but these errors were encountered: