This has the effect of totally cutting shatter attacks off at the knees - user apps can't interact with high privilege windows running in services. The third reason that interactive services is a bad idea is that interactive services aren't guaranteed to work with Windows Vista :) As a part of the security hardening process that went into Windows Vista, interactive users log onto sessions other than the system session - the first interactive user runs in session 1, not session 0. TS isn't that common, but in home scenarios where there are multiple people using a single computer, FUS is often enabled (we have 4 people logged in pretty much all the time on the computer in our kitchen, for example). There are two main scenarios that have a user connecting in another session - Terminal Services, and Fast User Switching. If, on the other hand, the user is running in another session, the user never sees the UI. The service UI pops up in the system session (normally session 0). The second reason it's a bad idea is that the SERVICE_INTERACTIVE_PROCESS flag simply doesn't work correctly. Initially the shatter attacks went after windows components that had background window message pumps (which have long been fixed), but they've also been used to attack 3rd party services that pop up UI. Microsoft also published KB article 327618 which extends the documentation about interactive services, and Michael Howard wrote an article about interactive services for the MSDN Library. If you do a search for "shatter attack", you can see some details of how these security threats work. The primary reason for this being a bad idea is that interactive services enable a class of threats known as "Shatter" attacks (because they "shatter windows", I believe). See what Larry Osterman wrote about it back in 2005: Although probably not totally impossible, Microsoft did everything to make this as hard as possible, as it enables so-called Shatter Attacks.
The code goes to the line "Notepad has been started by WatchdogService. WriteToEventLog("Notepad has been started by WatchdogService. GetExitCodeProcess(processInfo.hProcess, ref exitCode) WaitForSingleObject(processInfo.hProcess, Convert.ToUInt32(0xFFFFFFF)) Throw new Win32Exception(Marshal.GetLastWin32Error()) String currentDirectory = System.IO.Directory.GetCurrentDirectory() īool bRes = CreateProcessWithLogonW(user, null, password, 0,ĬurrentDirectory, ref startupInfo, out processInfo) Var processInfo = new ProcessInformation() The following code is in my windows service (C# using win32 function via P/Inkove, I skipped import signatures, they're all here - ): var startupInfo = new StartupInfo()Ĭb = Marshal.SizeOf(typeof(StartupInfo)), NET has nothing to do here, it's actually pure Win32 thing. Setting "Allow service to interact with desktop" doesn't help.įirst of all.
Even if I install my windows to run under current user account the service will run in session #0 anyway.
I'd emphasis on that the question is not about how to start a process under specific account (it's obvious - Process.Start(new ProcessStartInfo(".") )). So the question is: how to start a process from a window service in such a way that it run in currently logged in user's session? The problem is that a Window Services run in session #0, but a logged in user sessions are 1,2 etc.
Moreover that application should be started under specific user account. I need to start a program from Windows Service.