I'm trying to determine if another application is running as an administrator. There are 100's of SO questions about finding if your application is or not, but not for another application.
If I do var processes = Process.GetProcesses(); and loop through them, they don't appear to have any "Elevated" or "IsAdministrator" properties on them. I also found a function on here to get the Owner but they all come back as "My-Laptop\Me" so that's not working for me the way I hoped it would.
Is there a way to find this? I'm on Win 8.1 and would prefer something that works for 7 as well, but if it only works for 8.1+ that's totally fine.
Thanks!
EDIT:
My application has to run as an administrator.
You can use the technique from this answer, just replace Process.GetCurrentProcess().Handle with the Process.Handle of the other process.
If you look at the code (there's quite a bit of code there) it get the process "user token" (the permissions the process is running under) and checks if this token has the administrator role or not,
Assuming your process is not running as administrator, trying to get information about a process that is elevated via UAC (such as its MainWindowTitle) will throw an AccessDenied exception, where a non-elevated process will permit you access to that information. This assumes you also verify the owner of the process to check that it's you.
try
{
var foo = process.MainWindowTitle;
return false; //Process is not elevated
}
catch (Win32Exception ex)
{
return true; //Process is elevated if ex error code is AccessDenied
}
Related
I am creating a service which runs an .exe file on Windows 7. It must be done as a service due to complex requirements, so a console application is not possible.
I have written the following code, which works perfectly in a console application, however when placed in the service, the executable is never run.
ProcessStartInfo startInfo = new ProcessStartInfo();
try
{
startInfo.WorkingDirectory = "C:\\Folder";
startInfo.FileName = "MyApp.exe";
Process myProcess = Process.Start(startInfo);
}
catch (Exception ex)
{
using (StreamWriter writer = File.AppendText(path))
{
writer.WriteLine(ex.Message);
}
}
}
No errors are being thrown, but the application is simply not starting.
I have read that services cannot run an executable in a straightforward manner, and have modified the above code based on suggestions, however it does not work.
EDIT: I have configured the service manually as follows:
This question has been the cause of great frustration, and I have finally solved my problem. Yes, I have managed to make a service load a GUI application, even though everyone says that it is impossible. There is a warning though - the "fix" can be considered as exploiting a loophole in Windows, as the code which I used basically passes the Vista and Windows 7 UAC. Essentially, the application is always executed with full rights and bypasses the UAC.
If anyone has this same problem, what you need to do is iterate through a list of logged in users on the PC, and choose to open the UI application in this session (which has the user's desktop), rather than in session 0 where the service is supposed to be running (and which does not have a desktop).
For some people, this might not be a solution as it is not secure. But in my case, security is not a main concern, and I just needed it to work (had to be a service by force).
Hope this helps anyone who has the same problem that I had.
The other day, I came across an application that when you run it, it comes up with the UAC screen and requests to be run with administrator privileges. Clicking 'Yes' on the UAC screen runs the application like normal. The interesting thing is that if you click 'No', the application, instead of exiting, still runs, but runs in a limited user account (with less functionality, of course).
My question is, how can I configure my C# application to do this? I know my application can have an application manifest to run in elevated privileges, but how do I duplicate the kind of behavior I just explained above?
To do this with a different elevated application you can use a "launcher" (or the launcher is the "normal" app).
If you wanted three applications you might have a WinForms launcher something like:
[STAThread]
static void Main()
{
const int ERROR_CANCELLED = 1223;
try
{
Process.Start("el.exe");
// ran el in elevated node...
}
catch (Win32Exception ex)
{
if (ex.NativeErrorCode == ERROR_CANCELLED)
{
Process.Start("normal.exe");
}
}
}
If you were doing two applications, you could do something like:
[STAThread]
static void Main()
{
const int ERROR_CANCELLED = 1223;
try
{
Process.Start("el.exe");
// ran el in elevated node...
}
catch (Win32Exception ex)
{
if (ex.NativeErrorCode == ERROR_CANCELLED)
{
// "continue" as un-elevated app.
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new Form1());
}
}
}
You can keep all the code in one application. The application manifest does not request the application to be run elevated, it uses asInvoker level.
When the application is started, it tries to re-start itself elevated. I mean it starts another process with runas verb. If it succeeds, then the first instance just exists.
If elevation was not successful, then it continues to run with limited functionality.
But think about the user experience:
Not everyone in the world works as administrator. For them, elevation would not look as clicking Continue button, the UAC will ask them to provide user name and password of an administrator.
From this point of view, Microsoft recommended approach works great: run as regular user until you really need to elevate. All elevation points should be clearly marked in the UI. You can still use the same exe file to run non-elevated and elevated instances, yet you must implement a communication mechanism so the non-elevated instance can provide all the data to perform the operation requested by the user. Once you started elevated instance, you can keep it running and exit the non-elevated one, so that other operations could be performed without elevation.
Thus it means more effort, but a much better user experience.
I'm researching on how to add a shortcut in the windows context menu to my application. I came across this article and I tried it out. This is the code it uses to create a key in the registry.
private void btnAddMenu_Click(object sender, System.EventArgs e)
{
RegistryKey regmenu = null;
RegistryKey regcmd = null;
try
{
regmenu = Registry.ClassesRoot.CreateSubKey(MenuName);
if(regmenu != null)
regmenu.SetValue("",this.txtName.Text);
regcmd = Registry.ClassesRoot.CreateSubKey(Command);
if(regcmd != null)
regcmd.SetValue("",this.txtPath.Text);
}
catch(Exception ex)
{
MessageBox.Show(this,ex.ToString());
}
finally
{
if(regmenu != null)
regmenu.Close();
if(regcmd != null)
regcmd.Close();
}
}
The problem is if I run it through my Administrator account, it works fine. But when I do it through a different account which doesn't have admin privileges, it throws this exception.
system.unauthorizedaccessexception access to the registry key is denied
Now if I were to use this code in one of my own applications to create a shortcut in the context menu, I can't be sure every user would run it as the Administrator, right?
Is there any way in C# to escalate the user privileges when creating the registry key?
If you know any other way to add an item to the windows context menu, I'd be interested in them too.
Thank you.
You cannot escalate permissions as such (at least I'd like to know about it, but doesn't seem possible as yet), but you need to run / start your app (embed into manifest) elevated.
Please take a look at these entries...
How do I force my .NET application to run as administrator?
Elevating process privilege programatically?
I'd suggest what comments said, running that from the setup. Or let your app run as admin from the start, or possibly jump start an elevated process from your app - when needed (e.g. running another exe of yours that has its manifest properly).
You could escalate your permissions much the same way installers do it. It will require user interaction, as that's the way the OS is designed (and rightly so) - you can't go around it.
the following small line throws a System.Security.SecurityException: Requested registry access is not allowed:
RegistryKey _key = HKLM.OpenSubKey("path\\to\\my settings", false);
Now.. what's the point some would ask? The point is that this runs ONLY when I am logged on. The exception is thrown if the program runs as scheduled task and nobody is logged on.
the user who runs that task is local administrator
the program does not run from a network share, it is located on the local disk
I even tried setting Code Access Security
the user has the rights to log on as a batch job
I have XP SP3 with all patches applied. The program is written in C# .Net 2.0 (tested 3.5 too)
Does anyone know whats the point here?
Torsten
EDIT: see http://gist.github.com/638576
Mhhhh...it seems related to Authorization problem too. Have you tried to use the API: OpenSubKey(...., RegistryKeyPermissionCheck) to see if something change? I guess it could be related to parent key and its authorization.
Try to see: http://msdn.microsoft.com/it-it/library/microsoft.win32.registrykeypermissioncheck.aspx (in your language). I hope it could help you...
Can you adapt this
WindowsPrincipal principal = new WindowsPrincipal(WindowsIdentity.GetCurrent());
string isAdmin = principal.IsInRole(WindowsBuiltInRole.Administrator) ? "Yes" : "No";
to check that the process really is successfully impersonating when there's no current user?
It seems that this is a problem of this specific computer. I tested it on another workstation and it works even without administrator privileges.
I assumed this - the program did run for years without any problems... Anyway, thanks to all!
I am using the below code to disable the task manager for a kiosk application which works perfectly
public void DisableTaskManager()
{
RegistryKey regkey;
string keyValueInt = "1";
string subKey = "Software\\Microsoft\\Windows\\CurrentVersion\\Policies\\System";
try
{
regkey = Registry.CurrentUser.CreateSubKey(subKey);
regkey.SetValue("DisableTaskMgr", keyValueInt);
regkey.Close();
}
catch (Exception ex)
{
MessageBox.Show("DisableTaskManager" + ex.ToString());
}
}
But when i run this in OS hardened machine i get the following error,
DisableTaskManagerSystem.UnauthorizedAccessException:
Access to the registry key 'HKey_Current_User\Software\Mictrosoft\Windows\CurrentVersion\Policies\System' is denied.
at Microsoft.win32.RegistryKey.win32Error(int32 errorcode, String str)
How can i overcome this ? I need to do this for a Kiosk application.
take a look at this, im not yet a good enough C# Developer to comment but i know that during my work with other developers they came accross the UAC In windows 7, If thats what were talking about here.
http://www.aneef.net/2009/06/29/request-uac-elevation-for-net-application-managed-code/
Well the guy that set up that machine basically asked the reverse... "How do I prevent a non-administrator from messing with group policy". So rather engaging in a group policy arms race, you can either do it at install time when running as an admin, or just skip that part of the code when not running as a user that has permission to do so.
Don't have your application disable task manager but instead use a windows service or scheduled task. Your application is going to run in the context of the current user and won't have rights to the registry key. Instead you can create either a windows service or a scheduled task which can run as a user with higher privileges and can write to the registry.
With a windows service you can communicate it through any IPC mechanism such as custom service messages, Sockets, .NET Remoting, WCF, or whatever, to tell it to turn task manager on/off.
the code requires an elevated privilege to access registry. However there is just a fragment of code that requires these extra permission. To handle such scenarios impersonation is used i.e. you will execute this application as normal user only but that particular piece of code will be executed as if you were an Administrator.
http://msdn.microsoft.com/en-us/library/system.security.principal.windowsimpersonationcontext.aspx