2013-02-10 13:59:09 +00:00
|
|
|
/*
|
|
|
|
* COPYRIGHT: See COPYING in the top level directory
|
|
|
|
* PROJECT: ReactOS system libraries
|
|
|
|
* FILE: dll/win32/kernel32/client/console/init.c
|
|
|
|
* PURPOSE: Console API Client Initialization
|
2013-04-10 20:33:30 +00:00
|
|
|
* PROGRAMMERS: Alex Ionescu (alex.ionescu@reactos.org)
|
|
|
|
* Aleksey Bragin (aleksey@reactos.org)
|
|
|
|
* Hermes Belusca-Maito (hermes.belusca@sfr.fr)
|
2013-02-10 13:59:09 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
/* INCLUDES *******************************************************************/
|
|
|
|
|
|
|
|
#include <k32.h>
|
|
|
|
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
// For Control Panel Applet
|
|
|
|
#include <cpl.h>
|
|
|
|
|
2013-02-10 13:59:09 +00:00
|
|
|
#define NDEBUG
|
|
|
|
#include <debug.h>
|
|
|
|
|
|
|
|
|
|
|
|
/* GLOBALS ********************************************************************/
|
|
|
|
|
|
|
|
RTL_CRITICAL_SECTION ConsoleLock;
|
|
|
|
BOOL ConsoleInitialized = FALSE;
|
|
|
|
|
|
|
|
extern HANDLE InputWaitHandle;
|
|
|
|
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
static HMODULE ConsoleLibrary = NULL;
|
|
|
|
static BOOL AlreadyDisplayingProps = FALSE;
|
|
|
|
|
2013-02-10 13:59:09 +00:00
|
|
|
#define WIN_OBJ_DIR L"\\Windows"
|
|
|
|
#define SESSION_DIR L"\\Sessions"
|
|
|
|
|
|
|
|
|
|
|
|
/* FUNCTIONS ******************************************************************/
|
|
|
|
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
DWORD
|
|
|
|
WINAPI
|
|
|
|
PropDialogHandler(IN LPVOID lpThreadParameter)
|
|
|
|
{
|
|
|
|
// NOTE: lpThreadParameter corresponds to the client shared section handle.
|
|
|
|
|
|
|
|
APPLET_PROC CPLFunc;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Do not launch more than once the console property dialog applet,
|
|
|
|
* or (albeit less probable), if we are not initialized.
|
|
|
|
*/
|
|
|
|
if (!ConsoleInitialized || AlreadyDisplayingProps)
|
|
|
|
{
|
|
|
|
/* Close the associated client shared section handle if needed */
|
|
|
|
if (lpThreadParameter)
|
|
|
|
{
|
|
|
|
CloseHandle((HANDLE)lpThreadParameter);
|
|
|
|
}
|
|
|
|
return STATUS_UNSUCCESSFUL;
|
|
|
|
}
|
|
|
|
|
|
|
|
AlreadyDisplayingProps = TRUE;
|
|
|
|
|
|
|
|
/* Load the Control Applet if needed */
|
|
|
|
if (ConsoleLibrary == NULL)
|
|
|
|
{
|
|
|
|
WCHAR szBuffer[MAX_PATH];
|
|
|
|
|
2013-08-29 14:31:06 +00:00
|
|
|
GetSystemDirectoryW(szBuffer, MAX_PATH);
|
|
|
|
wcscat(szBuffer, L"\\console.dll");
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
ConsoleLibrary = LoadLibraryW(szBuffer);
|
|
|
|
|
|
|
|
if (ConsoleLibrary == NULL)
|
|
|
|
{
|
|
|
|
DPRINT1("Failed to load console.dll");
|
|
|
|
AlreadyDisplayingProps = FALSE;
|
|
|
|
return STATUS_UNSUCCESSFUL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Load its main function */
|
|
|
|
CPLFunc = (APPLET_PROC)GetProcAddress(ConsoleLibrary, "CPlApplet");
|
|
|
|
if (CPLFunc == NULL)
|
|
|
|
{
|
|
|
|
DPRINT("Error: Console.dll misses CPlApplet export\n");
|
|
|
|
AlreadyDisplayingProps = FALSE;
|
|
|
|
return STATUS_UNSUCCESSFUL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (CPLFunc(NULL, CPL_INIT, 0, 0) == FALSE)
|
|
|
|
{
|
|
|
|
DPRINT("Error: failed to initialize console.dll\n");
|
|
|
|
AlreadyDisplayingProps = FALSE;
|
|
|
|
return STATUS_UNSUCCESSFUL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (CPLFunc(NULL, CPL_GETCOUNT, 0, 0) != 1)
|
|
|
|
{
|
|
|
|
DPRINT("Error: console.dll returned unexpected CPL count\n");
|
|
|
|
AlreadyDisplayingProps = FALSE;
|
|
|
|
return STATUS_UNSUCCESSFUL;
|
|
|
|
}
|
|
|
|
|
|
|
|
CPLFunc(NULL, CPL_DBLCLK, (LPARAM)lpThreadParameter, 0);
|
|
|
|
CPLFunc(NULL, CPL_EXIT , 0, 0);
|
|
|
|
|
|
|
|
AlreadyDisplayingProps = FALSE;
|
|
|
|
return STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2013-02-10 13:59:09 +00:00
|
|
|
VOID
|
2013-06-16 17:16:33 +00:00
|
|
|
InitConsoleInfo(IN OUT PCONSOLE_START_INFO ConsoleStartInfo,
|
|
|
|
IN PUNICODE_STRING ImagePathName)
|
2013-02-10 13:59:09 +00:00
|
|
|
{
|
|
|
|
STARTUPINFOW si;
|
2013-06-16 17:16:33 +00:00
|
|
|
SIZE_T Length;
|
2013-02-10 13:59:09 +00:00
|
|
|
|
2013-06-16 17:16:33 +00:00
|
|
|
/* Get the startup information */
|
2013-02-10 13:59:09 +00:00
|
|
|
GetStartupInfoW(&si);
|
|
|
|
|
2013-06-16 17:16:33 +00:00
|
|
|
/* Initialize the fields */
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
ConsoleStartInfo->dwStartupFlags = si.dwFlags;
|
2013-02-10 13:59:09 +00:00
|
|
|
if (si.dwFlags & STARTF_USEFILLATTRIBUTE)
|
|
|
|
{
|
2013-09-14 10:20:11 +00:00
|
|
|
ConsoleStartInfo->wFillAttribute = (WORD)si.dwFillAttribute;
|
2013-02-10 13:59:09 +00:00
|
|
|
}
|
|
|
|
if (si.dwFlags & STARTF_USECOUNTCHARS)
|
|
|
|
{
|
2013-08-30 17:14:41 +00:00
|
|
|
ConsoleStartInfo->dwScreenBufferSize.X = (SHORT)(si.dwXCountChars);
|
|
|
|
ConsoleStartInfo->dwScreenBufferSize.Y = (SHORT)(si.dwYCountChars);
|
2013-02-10 13:59:09 +00:00
|
|
|
}
|
|
|
|
if (si.dwFlags & STARTF_USESHOWWINDOW)
|
|
|
|
{
|
2013-08-30 17:14:41 +00:00
|
|
|
ConsoleStartInfo->wShowWindow = si.wShowWindow;
|
2013-02-10 13:59:09 +00:00
|
|
|
}
|
|
|
|
if (si.dwFlags & STARTF_USEPOSITION)
|
|
|
|
{
|
2013-09-14 10:20:11 +00:00
|
|
|
ConsoleStartInfo->dwWindowOrigin.X = (SHORT)(si.dwX);
|
|
|
|
ConsoleStartInfo->dwWindowOrigin.Y = (SHORT)(si.dwY);
|
2013-02-10 13:59:09 +00:00
|
|
|
}
|
|
|
|
if (si.dwFlags & STARTF_USESIZE)
|
|
|
|
{
|
2013-09-14 10:20:11 +00:00
|
|
|
ConsoleStartInfo->dwWindowSize.X = (SHORT)(si.dwXSize);
|
|
|
|
ConsoleStartInfo->dwWindowSize.Y = (SHORT)(si.dwYSize);
|
2013-02-10 13:59:09 +00:00
|
|
|
}
|
|
|
|
|
2013-06-16 17:16:33 +00:00
|
|
|
/* Set up the title for the console */
|
2013-02-10 13:59:09 +00:00
|
|
|
if (si.lpTitle)
|
|
|
|
{
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
wcsncpy(ConsoleStartInfo->ConsoleTitle, si.lpTitle, MAX_PATH + 1);
|
2013-02-10 13:59:09 +00:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
ConsoleStartInfo->ConsoleTitle[0] = L'\0';
|
2013-02-10 13:59:09 +00:00
|
|
|
}
|
2013-06-16 17:16:33 +00:00
|
|
|
|
|
|
|
/* Retrieve the application path name */
|
|
|
|
Length = min(sizeof(ConsoleStartInfo->AppPath) / sizeof(ConsoleStartInfo->AppPath[0]) - 1,
|
|
|
|
ImagePathName->Length / sizeof(WCHAR));
|
|
|
|
wcsncpy(ConsoleStartInfo->AppPath, ImagePathName->Buffer, Length);
|
|
|
|
ConsoleStartInfo->AppPath[Length] = L'\0';
|
|
|
|
|
|
|
|
/* The Console Server will use these fields to set up the console icon */
|
|
|
|
ConsoleStartInfo->IconPath[0] = L'\0';
|
|
|
|
ConsoleStartInfo->IconIndex = 0;
|
2013-02-10 13:59:09 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
BOOL
|
|
|
|
WINAPI
|
|
|
|
BasepInitConsole(VOID)
|
|
|
|
{
|
|
|
|
NTSTATUS Status;
|
|
|
|
PRTL_USER_PROCESS_PARAMETERS Parameters = NtCurrentPeb()->ProcessParameters;
|
|
|
|
WCHAR SessionDir[256];
|
|
|
|
ULONG SessionId = NtCurrentPeb()->SessionId;
|
|
|
|
BOOLEAN InServer;
|
|
|
|
|
2013-08-19 18:14:43 +00:00
|
|
|
CONSRV_API_CONNECTINFO ConnectInfo;
|
2013-02-10 13:59:09 +00:00
|
|
|
ULONG ConnectInfoSize = sizeof(ConnectInfo);
|
|
|
|
|
|
|
|
DPRINT("BasepInitConsole for : %wZ\n", &Parameters->ImagePathName);
|
2013-08-29 20:37:02 +00:00
|
|
|
DPRINT("Our current console handles are: %p, %p, %p %p\n",
|
2013-02-10 13:59:09 +00:00
|
|
|
Parameters->ConsoleHandle, Parameters->StandardInput,
|
|
|
|
Parameters->StandardOutput, Parameters->StandardError);
|
|
|
|
|
|
|
|
/* Initialize our global console DLL lock */
|
|
|
|
Status = RtlInitializeCriticalSection(&ConsoleLock);
|
|
|
|
if (!NT_SUCCESS(Status)) return FALSE;
|
|
|
|
ConsoleInitialized = TRUE;
|
|
|
|
|
|
|
|
/* Do nothing if this isn't a console app... */
|
|
|
|
if (RtlImageNtHeader(GetModuleHandle(NULL))->OptionalHeader.Subsystem !=
|
|
|
|
IMAGE_SUBSYSTEM_WINDOWS_CUI)
|
|
|
|
{
|
|
|
|
DPRINT("Image is not a console application\n");
|
|
|
|
Parameters->ConsoleHandle = NULL;
|
2013-08-30 17:14:41 +00:00
|
|
|
ConnectInfo.ConsoleStartInfo.ConsoleNeeded = FALSE; // ConsoleNeeded is used for knowing whether or not this is a CUI app.
|
2013-02-10 13:59:09 +00:00
|
|
|
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
ConnectInfo.ConsoleStartInfo.ConsoleTitle[0] = L'\0';
|
2013-03-24 17:08:10 +00:00
|
|
|
ConnectInfo.ConsoleStartInfo.AppPath[0] = L'\0';
|
2013-02-10 13:59:09 +00:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
LPCWSTR ExeName;
|
|
|
|
|
2013-06-16 17:16:33 +00:00
|
|
|
InitConsoleInfo(&ConnectInfo.ConsoleStartInfo,
|
|
|
|
&Parameters->ImagePathName);
|
2013-02-10 13:59:09 +00:00
|
|
|
|
|
|
|
/* Initialize Input EXE name */
|
|
|
|
ExeName = wcsrchr(Parameters->ImagePathName.Buffer, L'\\');
|
|
|
|
if (ExeName) SetConsoleInputExeNameW(ExeName + 1);
|
|
|
|
|
|
|
|
/* Assume one is needed */
|
2013-08-30 17:14:41 +00:00
|
|
|
ConnectInfo.ConsoleStartInfo.ConsoleNeeded = TRUE;
|
2013-02-10 13:59:09 +00:00
|
|
|
|
|
|
|
/* Handle the special flags given to us by BasePushProcessParameters */
|
|
|
|
if (Parameters->ConsoleHandle == HANDLE_DETACHED_PROCESS)
|
|
|
|
{
|
|
|
|
/* No console to create */
|
|
|
|
DPRINT("No console to create\n");
|
|
|
|
Parameters->ConsoleHandle = NULL;
|
2013-08-30 17:14:41 +00:00
|
|
|
ConnectInfo.ConsoleStartInfo.ConsoleNeeded = FALSE;
|
2013-02-10 13:59:09 +00:00
|
|
|
}
|
|
|
|
else if (Parameters->ConsoleHandle == HANDLE_CREATE_NEW_CONSOLE)
|
|
|
|
{
|
|
|
|
/* We'll get the real one soon */
|
|
|
|
DPRINT("Creating new console\n");
|
|
|
|
Parameters->ConsoleHandle = NULL;
|
|
|
|
}
|
|
|
|
else if (Parameters->ConsoleHandle == HANDLE_CREATE_NO_WINDOW)
|
|
|
|
{
|
|
|
|
/* We'll get the real one soon */
|
|
|
|
DPRINT("Creating new invisible console\n");
|
|
|
|
Parameters->ConsoleHandle = NULL;
|
2013-08-30 17:14:41 +00:00
|
|
|
ConnectInfo.ConsoleStartInfo.wShowWindow = SW_HIDE;
|
2013-02-10 13:59:09 +00:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
if (Parameters->ConsoleHandle == INVALID_HANDLE_VALUE)
|
|
|
|
{
|
|
|
|
Parameters->ConsoleHandle = NULL;
|
|
|
|
}
|
2013-08-29 20:37:02 +00:00
|
|
|
DPRINT("Using existing console: %p\n", Parameters->ConsoleHandle);
|
2013-02-10 13:59:09 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Now use the proper console handle */
|
2013-07-06 19:57:38 +00:00
|
|
|
ConnectInfo.ConsoleHandle = Parameters->ConsoleHandle;
|
2013-02-10 13:59:09 +00:00
|
|
|
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
/* Initialize the Console Ctrl Handler */
|
2013-02-10 13:59:09 +00:00
|
|
|
InitConsoleCtrlHandling();
|
2013-08-30 17:14:41 +00:00
|
|
|
ConnectInfo.ConsoleStartInfo.CtrlDispatcher = ConsoleControlDispatcher;
|
2013-02-10 13:59:09 +00:00
|
|
|
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
/* Initialize the Property Dialog Handler */
|
2013-08-30 17:14:41 +00:00
|
|
|
ConnectInfo.ConsoleStartInfo.PropDispatcher = PropDialogHandler;
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
|
2013-02-10 13:59:09 +00:00
|
|
|
/* Setup the right Object Directory path */
|
|
|
|
if (!SessionId)
|
|
|
|
{
|
|
|
|
/* Use the raw path */
|
|
|
|
wcscpy(SessionDir, WIN_OBJ_DIR);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* Use the session path */
|
|
|
|
swprintf(SessionDir,
|
|
|
|
L"%ws\\%ld%ws",
|
|
|
|
SESSION_DIR,
|
|
|
|
SessionId,
|
|
|
|
WIN_OBJ_DIR);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Connect to the Console Server */
|
|
|
|
DPRINT("Connecting to the Console Server in BasepInitConsole...\n");
|
|
|
|
Status = CsrClientConnectToServer(SessionDir,
|
|
|
|
CONSRV_SERVERDLL_INDEX,
|
|
|
|
&ConnectInfo,
|
|
|
|
&ConnectInfoSize,
|
|
|
|
&InServer);
|
|
|
|
if (!NT_SUCCESS(Status))
|
|
|
|
{
|
|
|
|
DPRINT1("Failed to connect to the Console Server (Status %lx)\n", Status);
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Nothing to do for server-to-server */
|
|
|
|
if (InServer) return TRUE;
|
|
|
|
|
|
|
|
/* Nothing to do if not a console app */
|
2013-08-30 17:14:41 +00:00
|
|
|
if (!ConnectInfo.ConsoleStartInfo.ConsoleNeeded) return TRUE;
|
2013-02-10 13:59:09 +00:00
|
|
|
|
|
|
|
/* We got the handles, let's set them */
|
2013-07-06 19:57:38 +00:00
|
|
|
if ((Parameters->ConsoleHandle = ConnectInfo.ConsoleHandle))
|
2013-02-10 13:59:09 +00:00
|
|
|
{
|
|
|
|
/* If we already had some, don't use the new ones */
|
|
|
|
if (!Parameters->StandardInput)
|
|
|
|
{
|
|
|
|
Parameters->StandardInput = ConnectInfo.InputHandle;
|
|
|
|
}
|
|
|
|
if (!Parameters->StandardOutput)
|
|
|
|
{
|
|
|
|
Parameters->StandardOutput = ConnectInfo.OutputHandle;
|
|
|
|
}
|
|
|
|
if (!Parameters->StandardError)
|
|
|
|
{
|
|
|
|
Parameters->StandardError = ConnectInfo.ErrorHandle;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
InputWaitHandle = ConnectInfo.InputWaitHandle;
|
|
|
|
|
2013-08-29 20:37:02 +00:00
|
|
|
DPRINT("Console setup: %p, %p, %p, %p\n",
|
2013-02-10 13:59:09 +00:00
|
|
|
Parameters->ConsoleHandle,
|
|
|
|
Parameters->StandardInput,
|
|
|
|
Parameters->StandardOutput,
|
|
|
|
Parameters->StandardError);
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
VOID
|
|
|
|
WINAPI
|
|
|
|
BasepUninitConsole(VOID)
|
|
|
|
{
|
|
|
|
/* Delete our critical section if we were initialized */
|
|
|
|
if (ConsoleInitialized == TRUE)
|
|
|
|
{
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
if (ConsoleLibrary) FreeLibrary(ConsoleLibrary);
|
|
|
|
|
2013-02-10 13:59:09 +00:00
|
|
|
ConsoleInitialized = FALSE;
|
|
|
|
RtlDeleteCriticalSection(&ConsoleLock);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* EOF */
|