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;
|
2014-09-07 22:53:49 +00:00
|
|
|
BOOLEAN ConsoleInitialized = FALSE;
|
2013-02-10 13:59:09 +00:00
|
|
|
extern HANDLE InputWaitHandle;
|
|
|
|
|
2014-09-07 22:53:49 +00:00
|
|
|
static const PWSTR DefaultConsoleTitle = L"ReactOS Console";
|
2013-02-10 13:59:09 +00:00
|
|
|
|
|
|
|
/* 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.
|
|
|
|
|
2014-09-07 22:53:49 +00:00
|
|
|
NTSTATUS Status = STATUS_SUCCESS;
|
2015-03-24 23:58:44 +00:00
|
|
|
HMODULE hConsoleApplet = NULL;
|
|
|
|
APPLET_PROC CPlApplet;
|
|
|
|
static BOOL AlreadyDisplayingProps = FALSE;
|
|
|
|
WCHAR szBuffer[MAX_PATH];
|
[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
|
|
|
|
|
|
|
/*
|
|
|
|
* 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);
|
2015-03-24 23:58:44 +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
|
|
|
return STATUS_UNSUCCESSFUL;
|
|
|
|
}
|
|
|
|
|
|
|
|
AlreadyDisplayingProps = TRUE;
|
|
|
|
|
2015-03-24 23:58:44 +00:00
|
|
|
/* Load the control applet */
|
|
|
|
GetSystemDirectoryW(szBuffer, MAX_PATH);
|
|
|
|
wcscat(szBuffer, L"\\console.dll");
|
|
|
|
hConsoleApplet = LoadLibraryW(szBuffer);
|
|
|
|
if (hConsoleApplet == NULL)
|
[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
|
|
|
{
|
2015-03-24 23:58:44 +00:00
|
|
|
DPRINT1("Failed to load console.dll\n");
|
|
|
|
Status = STATUS_UNSUCCESSFUL;
|
|
|
|
goto Quit;
|
[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
|
|
|
}
|
|
|
|
|
|
|
|
/* Load its main function */
|
2015-03-24 23:58:44 +00:00
|
|
|
CPlApplet = (APPLET_PROC)GetProcAddress(hConsoleApplet, "CPlApplet");
|
|
|
|
if (CPlApplet == NULL)
|
[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
|
|
|
{
|
2015-03-24 23:58:44 +00:00
|
|
|
DPRINT1("Error: console.dll misses CPlApplet export\n");
|
2014-09-07 22:53:49 +00:00
|
|
|
Status = STATUS_UNSUCCESSFUL;
|
|
|
|
goto Quit;
|
[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
|
|
|
}
|
|
|
|
|
2015-03-24 23:58:44 +00:00
|
|
|
/* Initialize the applet */
|
|
|
|
if (CPlApplet(NULL, CPL_INIT, 0, 0) == FALSE)
|
[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
|
|
|
{
|
2014-09-07 22:53:49 +00:00
|
|
|
DPRINT1("Error: failed to initialize console.dll\n");
|
|
|
|
Status = STATUS_UNSUCCESSFUL;
|
|
|
|
goto Quit;
|
[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
|
|
|
}
|
|
|
|
|
2015-03-24 23:58:44 +00:00
|
|
|
/* Check the count */
|
|
|
|
if (CPlApplet(NULL, CPL_GETCOUNT, 0, 0) != 1)
|
[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
|
|
|
{
|
2014-09-07 22:53:49 +00:00
|
|
|
DPRINT1("Error: console.dll returned unexpected CPL count\n");
|
|
|
|
Status = STATUS_UNSUCCESSFUL;
|
|
|
|
goto Quit;
|
[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
|
|
|
}
|
|
|
|
|
2015-03-24 23:58:44 +00:00
|
|
|
/*
|
|
|
|
* Start the applet. For Windows compatibility purposes we need
|
|
|
|
* to pass the client shared section handle (lpThreadParameter)
|
|
|
|
* via the hWnd parameter of the CPlApplet function.
|
|
|
|
*/
|
|
|
|
CPlApplet((HWND)lpThreadParameter, CPL_DBLCLK, 0, 0);
|
|
|
|
|
|
|
|
/* We have finished */
|
|
|
|
CPlApplet(NULL, CPL_EXIT, 0, 0);
|
[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
|
|
|
|
2014-09-07 22:53:49 +00:00
|
|
|
Quit:
|
2015-03-24 23:58:44 +00:00
|
|
|
if (hConsoleApplet) FreeLibrary(hConsoleApplet);
|
[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
|
|
|
AlreadyDisplayingProps = FALSE;
|
2014-09-07 22:53:49 +00:00
|
|
|
return Status;
|
[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
|
|
|
}
|
|
|
|
|
|
|
|
|
2014-09-07 22:53:49 +00:00
|
|
|
static INT
|
|
|
|
ParseShellInfo(LPCWSTR lpszShellInfo,
|
|
|
|
LPCWSTR lpszKeyword)
|
2013-02-10 13:59:09 +00:00
|
|
|
{
|
2015-02-15 23:55:52 +00:00
|
|
|
DPRINT("ParseShellInfo is UNIMPLEMENTED\n");
|
2014-09-07 22:53:49 +00:00
|
|
|
return 0;
|
|
|
|
}
|
2013-02-10 13:59:09 +00:00
|
|
|
|
2014-09-07 22:53:49 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* NOTE:
|
|
|
|
* The "LPDWORD Length" parameters point on input to the maximum size of
|
|
|
|
* the buffers that can hold data (if != 0), and on output they hold the
|
|
|
|
* real size of the data. If "Length" are == 0 on input, then on output
|
|
|
|
* they receive the full size of the data.
|
|
|
|
* The "LPWSTR* lpTitle" parameter has a double meaning:
|
|
|
|
* - when "CaptureTitle" is TRUE, data is copied to the buffer pointed
|
|
|
|
* by the pointer (*lpTitle).
|
|
|
|
* - when "CaptureTitle" is FALSE, "*lpTitle" is set to the address of
|
|
|
|
* the source data.
|
|
|
|
*/
|
|
|
|
VOID
|
|
|
|
SetUpConsoleInfo(IN BOOLEAN CaptureTitle,
|
|
|
|
IN OUT LPDWORD pTitleLength,
|
|
|
|
IN OUT LPWSTR* lpTitle OPTIONAL,
|
|
|
|
IN OUT LPDWORD pDesktopLength,
|
|
|
|
IN OUT LPWSTR* lpDesktop OPTIONAL,
|
|
|
|
IN OUT PCONSOLE_START_INFO ConsoleStartInfo)
|
|
|
|
{
|
|
|
|
PRTL_USER_PROCESS_PARAMETERS Parameters = NtCurrentPeb()->ProcessParameters;
|
|
|
|
DWORD Length;
|
2013-02-10 13:59:09 +00:00
|
|
|
|
2013-06-16 17:16:33 +00:00
|
|
|
/* Initialize the fields */
|
2014-09-07 22:53:49 +00:00
|
|
|
|
|
|
|
ConsoleStartInfo->IconIndex = 0;
|
|
|
|
ConsoleStartInfo->hIcon = NULL;
|
|
|
|
ConsoleStartInfo->hIconSm = NULL;
|
|
|
|
ConsoleStartInfo->dwStartupFlags = Parameters->WindowFlags;
|
|
|
|
ConsoleStartInfo->nFont = 0;
|
|
|
|
ConsoleStartInfo->nInputBufferSize = 0;
|
|
|
|
ConsoleStartInfo->uCodePage = GetOEMCP();
|
|
|
|
|
|
|
|
if (lpTitle)
|
2013-02-10 13:59:09 +00:00
|
|
|
{
|
2014-09-07 22:53:49 +00:00
|
|
|
LPWSTR Title;
|
|
|
|
|
|
|
|
/* If we don't have any title, use the default one */
|
|
|
|
if (Parameters->WindowTitle.Buffer == NULL)
|
|
|
|
{
|
|
|
|
Title = DefaultConsoleTitle;
|
|
|
|
Length = lstrlenW(DefaultConsoleTitle) * sizeof(WCHAR); // sizeof(DefaultConsoleTitle);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
Title = Parameters->WindowTitle.Buffer;
|
|
|
|
Length = Parameters->WindowTitle.Length;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Retrieve the needed buffer size */
|
|
|
|
Length += sizeof(WCHAR);
|
|
|
|
if (*pTitleLength > 0) Length = min(Length, *pTitleLength);
|
|
|
|
*pTitleLength = Length;
|
|
|
|
|
|
|
|
/* Capture the data if needed, or, return a pointer to it */
|
|
|
|
if (CaptureTitle)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Length is always >= sizeof(WCHAR). Copy everything but the
|
|
|
|
* possible trailing NULL character, and then NULL-terminate.
|
|
|
|
*/
|
|
|
|
Length -= sizeof(WCHAR);
|
|
|
|
RtlCopyMemory(*lpTitle, Title, Length);
|
|
|
|
(*lpTitle)[Length / sizeof(WCHAR)] = UNICODE_NULL;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
*lpTitle = Title;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
*pTitleLength = 0;
|
2013-02-10 13:59:09 +00:00
|
|
|
}
|
2014-09-07 22:53:49 +00:00
|
|
|
|
|
|
|
if (lpDesktop && Parameters->DesktopInfo.Buffer && *Parameters->DesktopInfo.Buffer)
|
2013-02-10 13:59:09 +00:00
|
|
|
{
|
2014-09-07 22:53:49 +00:00
|
|
|
/* Retrieve the needed buffer size */
|
|
|
|
Length = Parameters->DesktopInfo.Length + sizeof(WCHAR);
|
|
|
|
if (*pDesktopLength > 0) Length = min(Length, *pDesktopLength);
|
|
|
|
*pDesktopLength = Length;
|
|
|
|
|
|
|
|
/* Return a pointer to the data */
|
|
|
|
*lpDesktop = Parameters->DesktopInfo.Buffer;
|
2013-02-10 13:59:09 +00:00
|
|
|
}
|
2014-09-07 22:53:49 +00:00
|
|
|
else
|
2013-02-10 13:59:09 +00:00
|
|
|
{
|
2014-09-07 22:53:49 +00:00
|
|
|
*pDesktopLength = 0;
|
|
|
|
if (lpDesktop) *lpDesktop = NULL;
|
2013-02-10 13:59:09 +00:00
|
|
|
}
|
2014-09-07 22:53:49 +00:00
|
|
|
|
|
|
|
if (Parameters->WindowFlags & STARTF_USEFILLATTRIBUTE)
|
|
|
|
{
|
|
|
|
ConsoleStartInfo->wFillAttribute = (WORD)Parameters->FillAttribute;
|
|
|
|
}
|
|
|
|
if (Parameters->WindowFlags & STARTF_USECOUNTCHARS)
|
2013-02-10 13:59:09 +00:00
|
|
|
{
|
2014-09-07 22:53:49 +00:00
|
|
|
ConsoleStartInfo->dwScreenBufferSize.X = (SHORT)Parameters->CountCharsX;
|
|
|
|
ConsoleStartInfo->dwScreenBufferSize.Y = (SHORT)Parameters->CountCharsY;
|
2013-02-10 13:59:09 +00:00
|
|
|
}
|
2014-09-07 22:53:49 +00:00
|
|
|
if (Parameters->WindowFlags & STARTF_USESHOWWINDOW)
|
2013-02-10 13:59:09 +00:00
|
|
|
{
|
2014-09-07 22:53:49 +00:00
|
|
|
ConsoleStartInfo->wShowWindow = (WORD)Parameters->ShowWindowFlags;
|
|
|
|
}
|
|
|
|
if (Parameters->WindowFlags & STARTF_USEPOSITION)
|
|
|
|
{
|
|
|
|
ConsoleStartInfo->dwWindowOrigin.X = (SHORT)Parameters->StartingX;
|
|
|
|
ConsoleStartInfo->dwWindowOrigin.Y = (SHORT)Parameters->StartingY;
|
|
|
|
}
|
|
|
|
if (Parameters->WindowFlags & STARTF_USESIZE)
|
|
|
|
{
|
|
|
|
ConsoleStartInfo->dwWindowSize.X = (SHORT)Parameters->CountX;
|
|
|
|
ConsoleStartInfo->dwWindowSize.Y = (SHORT)Parameters->CountY;
|
2013-02-10 13:59:09 +00:00
|
|
|
}
|
|
|
|
|
2014-09-07 22:53:49 +00:00
|
|
|
/* Get shell information (ShellInfo.Buffer is NULL-terminated) */
|
|
|
|
if (Parameters->ShellInfo.Buffer != NULL)
|
2013-02-10 13:59:09 +00:00
|
|
|
{
|
2014-09-07 22:53:49 +00:00
|
|
|
ConsoleStartInfo->IconIndex = ParseShellInfo(Parameters->ShellInfo.Buffer, L"dde.");
|
|
|
|
|
|
|
|
if ((Parameters->WindowFlags & STARTF_USEHOTKEY) == 0)
|
|
|
|
ConsoleStartInfo->dwHotKey = ParseShellInfo(Parameters->ShellInfo.Buffer, L"hotkey.");
|
|
|
|
else
|
|
|
|
ConsoleStartInfo->dwHotKey = HandleToUlong(Parameters->StandardInput);
|
2013-02-10 13:59:09 +00:00
|
|
|
}
|
2014-09-07 22:53:49 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
VOID
|
|
|
|
SetUpHandles(IN PCONSOLE_START_INFO ConsoleStartInfo)
|
|
|
|
{
|
|
|
|
PRTL_USER_PROCESS_PARAMETERS Parameters = NtCurrentPeb()->ProcessParameters;
|
|
|
|
|
|
|
|
if (ConsoleStartInfo->dwStartupFlags & STARTF_USEHOTKEY)
|
|
|
|
{
|
|
|
|
Parameters->WindowFlags &= ~STARTF_USEHOTKEY;
|
|
|
|
}
|
|
|
|
if (ConsoleStartInfo->dwStartupFlags & STARTF_SHELLPRIVATE)
|
|
|
|
{
|
|
|
|
Parameters->WindowFlags &= ~STARTF_SHELLPRIVATE;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* We got the handles, let's set them */
|
|
|
|
Parameters->ConsoleHandle = ConsoleStartInfo->ConsoleHandle;
|
|
|
|
|
2014-09-09 21:24:44 +00:00
|
|
|
if ((ConsoleStartInfo->dwStartupFlags & STARTF_USESTDHANDLES) == 0)
|
2013-02-10 13:59:09 +00:00
|
|
|
{
|
2014-09-07 22:53:49 +00:00
|
|
|
Parameters->StandardInput = ConsoleStartInfo->InputHandle;
|
|
|
|
Parameters->StandardOutput = ConsoleStartInfo->OutputHandle;
|
|
|
|
Parameters->StandardError = ConsoleStartInfo->ErrorHandle;
|
2013-02-10 13:59:09 +00:00
|
|
|
}
|
2014-09-07 22:53:49 +00:00
|
|
|
}
|
2013-06-16 17:16:33 +00:00
|
|
|
|
|
|
|
|
2014-09-07 22:53:49 +00:00
|
|
|
static BOOLEAN
|
|
|
|
IsConsoleApp(VOID)
|
|
|
|
{
|
|
|
|
PIMAGE_NT_HEADERS ImageNtHeader = RtlImageNtHeader(NtCurrentPeb()->ImageBaseAddress);
|
|
|
|
return (ImageNtHeader && (ImageNtHeader->OptionalHeader.Subsystem ==
|
|
|
|
IMAGE_SUBSYSTEM_WINDOWS_CUI));
|
2013-02-10 13:59:09 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2014-09-07 22:53:49 +00:00
|
|
|
static BOOLEAN
|
|
|
|
ConnectConsole(IN PWSTR SessionDir,
|
|
|
|
IN PCONSRV_API_CONNECTINFO ConnectInfo,
|
2014-12-17 22:07:41 +00:00
|
|
|
OUT PBOOLEAN InServerProcess)
|
2014-09-07 22:53:49 +00:00
|
|
|
{
|
|
|
|
NTSTATUS Status;
|
|
|
|
ULONG ConnectInfoSize = sizeof(*ConnectInfo);
|
|
|
|
|
|
|
|
ASSERT(SessionDir);
|
|
|
|
|
|
|
|
/* Connect to the Console Server */
|
|
|
|
DPRINT("Connecting to the Console Server...\n");
|
|
|
|
Status = CsrClientConnectToServer(SessionDir,
|
|
|
|
CONSRV_SERVERDLL_INDEX,
|
|
|
|
ConnectInfo,
|
|
|
|
&ConnectInfoSize,
|
2014-12-17 22:07:41 +00:00
|
|
|
InServerProcess);
|
2014-09-07 22:53:49 +00:00
|
|
|
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 */
|
2014-12-17 22:07:41 +00:00
|
|
|
if (*InServerProcess) return TRUE;
|
2014-09-07 22:53:49 +00:00
|
|
|
|
|
|
|
/* Nothing to do if this is not a console app */
|
|
|
|
if (!ConnectInfo->IsConsoleApp) return TRUE;
|
|
|
|
|
|
|
|
/* Wait for the connection to finish */
|
2014-11-22 22:13:08 +00:00
|
|
|
// Is ConnectInfo->ConsoleStartInfo.InitEvents aligned on handle boundary ????
|
|
|
|
Status = NtWaitForMultipleObjects(MAX_INIT_EVENTS,
|
|
|
|
ConnectInfo->ConsoleStartInfo.InitEvents,
|
2014-09-07 22:53:49 +00:00
|
|
|
WaitAny, FALSE, NULL);
|
|
|
|
if (!NT_SUCCESS(Status))
|
|
|
|
{
|
|
|
|
BaseSetLastNTError(Status);
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
2014-11-22 22:13:08 +00:00
|
|
|
NtClose(ConnectInfo->ConsoleStartInfo.InitEvents[INIT_SUCCESS]);
|
|
|
|
NtClose(ConnectInfo->ConsoleStartInfo.InitEvents[INIT_FAILURE]);
|
|
|
|
if (Status != INIT_SUCCESS)
|
2014-09-07 22:53:49 +00:00
|
|
|
{
|
|
|
|
NtCurrentPeb()->ProcessParameters->ConsoleHandle = NULL;
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
BOOLEAN
|
2013-02-10 13:59:09 +00:00
|
|
|
WINAPI
|
2014-09-07 22:53:49 +00:00
|
|
|
ConDllInitialize(IN ULONG Reason,
|
|
|
|
IN PWSTR SessionDir)
|
2013-02-10 13:59:09 +00:00
|
|
|
{
|
|
|
|
NTSTATUS Status;
|
|
|
|
PRTL_USER_PROCESS_PARAMETERS Parameters = NtCurrentPeb()->ProcessParameters;
|
2014-12-17 22:07:41 +00:00
|
|
|
BOOLEAN InServerProcess = FALSE;
|
2013-08-19 18:14:43 +00:00
|
|
|
CONSRV_API_CONNECTINFO ConnectInfo;
|
2014-09-07 22:53:49 +00:00
|
|
|
LCID lcid;
|
2013-02-10 13:59:09 +00:00
|
|
|
|
2014-09-07 22:53:49 +00:00
|
|
|
if (Reason != DLL_PROCESS_ATTACH)
|
|
|
|
{
|
2014-09-09 21:24:44 +00:00
|
|
|
if ((Reason == DLL_THREAD_ATTACH) && IsConsoleApp())
|
|
|
|
{
|
|
|
|
/* Sets the current console locale for the new thread */
|
|
|
|
SetTEBLangID(lcid);
|
|
|
|
}
|
|
|
|
else if (Reason == DLL_PROCESS_DETACH)
|
|
|
|
{
|
|
|
|
/* Free our resources */
|
2017-10-01 14:42:04 +00:00
|
|
|
if (ConsoleInitialized != FALSE)
|
2014-09-09 21:24:44 +00:00
|
|
|
{
|
|
|
|
ConsoleInitialized = FALSE;
|
|
|
|
RtlDeleteCriticalSection(&ConsoleLock);
|
|
|
|
}
|
|
|
|
}
|
2014-09-07 22:53:49 +00:00
|
|
|
|
2014-09-09 21:24:44 +00:00
|
|
|
return TRUE;
|
2014-09-07 22:53:49 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
DPRINT("ConDllInitialize for: %wZ\n"
|
|
|
|
"Our current console handles are: 0x%p, 0x%p, 0x%p 0x%p\n",
|
|
|
|
&Parameters->ImagePathName,
|
|
|
|
Parameters->ConsoleHandle,
|
|
|
|
Parameters->StandardInput,
|
|
|
|
Parameters->StandardOutput,
|
|
|
|
Parameters->StandardError);
|
2013-02-10 13:59:09 +00:00
|
|
|
|
|
|
|
/* Initialize our global console DLL lock */
|
|
|
|
Status = RtlInitializeCriticalSection(&ConsoleLock);
|
|
|
|
if (!NT_SUCCESS(Status)) return FALSE;
|
|
|
|
ConsoleInitialized = TRUE;
|
|
|
|
|
2014-09-07 22:53:49 +00:00
|
|
|
/* Show by default the console window when applicable */
|
|
|
|
ConnectInfo.IsWindowVisible = TRUE;
|
|
|
|
/* If this is a console app, a console will be created/opened */
|
|
|
|
ConnectInfo.IsConsoleApp = IsConsoleApp();
|
|
|
|
|
|
|
|
/* Do nothing if this is not a console app... */
|
|
|
|
if (!ConnectInfo.IsConsoleApp)
|
2013-02-10 13:59:09 +00:00
|
|
|
{
|
|
|
|
DPRINT("Image is not a console application\n");
|
2014-09-07 22:53:49 +00:00
|
|
|
}
|
2013-02-10 13:59:09 +00:00
|
|
|
|
2014-09-07 22:53:49 +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");
|
|
|
|
/*
|
|
|
|
* The new process does not inherit its parent's console and cannot
|
|
|
|
* attach to the console of its parent. The new process can call the
|
|
|
|
* AllocConsole function at a later time to create a console.
|
|
|
|
*/
|
|
|
|
Parameters->ConsoleHandle = NULL; // Do not inherit the parent's console.
|
|
|
|
ConnectInfo.IsConsoleApp = FALSE; // Do not create any console.
|
|
|
|
}
|
|
|
|
else if (Parameters->ConsoleHandle == HANDLE_CREATE_NEW_CONSOLE)
|
|
|
|
{
|
|
|
|
/* We'll get the real one soon */
|
|
|
|
DPRINT("Creating a new separate console\n");
|
|
|
|
/*
|
|
|
|
* The new process has a new console, instead of inheriting
|
|
|
|
* its parent's console.
|
|
|
|
*/
|
|
|
|
Parameters->ConsoleHandle = NULL; // Do not inherit the parent's console.
|
|
|
|
}
|
|
|
|
else if (Parameters->ConsoleHandle == HANDLE_CREATE_NO_WINDOW)
|
|
|
|
{
|
|
|
|
/* We'll get the real one soon */
|
|
|
|
DPRINT("Creating a new invisible console\n");
|
|
|
|
/*
|
|
|
|
* The process is a console application that is being run
|
|
|
|
* without a console window. Therefore, the console handle
|
|
|
|
* for the application is not set.
|
|
|
|
*/
|
|
|
|
Parameters->ConsoleHandle = NULL; // Do not inherit the parent's console.
|
|
|
|
ConnectInfo.IsWindowVisible = FALSE; // A console is created but is not shown to the user.
|
2013-02-10 13:59:09 +00:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2014-09-07 22:53:49 +00:00
|
|
|
DPRINT("Using existing console: 0x%p\n", Parameters->ConsoleHandle);
|
|
|
|
}
|
2013-02-10 13:59:09 +00:00
|
|
|
|
2014-09-07 22:53:49 +00:00
|
|
|
/* Do nothing if this is not a console app... */
|
|
|
|
if (!ConnectInfo.IsConsoleApp)
|
|
|
|
{
|
|
|
|
/* Do not inherit the parent's console if we are not a console app */
|
|
|
|
Parameters->ConsoleHandle = NULL;
|
|
|
|
}
|
2013-02-10 13:59:09 +00:00
|
|
|
|
2014-09-07 22:53:49 +00:00
|
|
|
/* Now use the proper console handle */
|
|
|
|
ConnectInfo.ConsoleStartInfo.ConsoleHandle = Parameters->ConsoleHandle;
|
2013-02-10 13:59:09 +00:00
|
|
|
|
2014-09-07 22:53:49 +00:00
|
|
|
/* Initialize the console dispatchers */
|
|
|
|
ConnectInfo.CtrlRoutine = ConsoleControlDispatcher;
|
|
|
|
ConnectInfo.PropRoutine = PropDialogHandler;
|
|
|
|
// ConnectInfo.ImeRoutine = ImeRoutine;
|
2013-02-10 13:59:09 +00:00
|
|
|
|
2014-09-07 22:53:49 +00:00
|
|
|
/* Set up the console properties */
|
|
|
|
if (ConnectInfo.IsConsoleApp && Parameters->ConsoleHandle == NULL)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* We can set up the console properties only if we create a new one
|
|
|
|
* (we do not inherit it from our parent).
|
|
|
|
*/
|
|
|
|
|
|
|
|
LPWSTR ConsoleTitle = ConnectInfo.ConsoleTitle;
|
|
|
|
|
|
|
|
ConnectInfo.TitleLength = sizeof(ConnectInfo.ConsoleTitle);
|
|
|
|
ConnectInfo.DesktopLength = 0; // SetUpConsoleInfo will give us the real length.
|
|
|
|
|
|
|
|
SetUpConsoleInfo(TRUE,
|
|
|
|
&ConnectInfo.TitleLength,
|
|
|
|
&ConsoleTitle,
|
|
|
|
&ConnectInfo.DesktopLength,
|
|
|
|
&ConnectInfo.Desktop,
|
|
|
|
&ConnectInfo.ConsoleStartInfo);
|
|
|
|
DPRINT("ConsoleTitle = '%S' - Desktop = '%S'\n",
|
|
|
|
ConsoleTitle, ConnectInfo.Desktop);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
ConnectInfo.TitleLength = 0;
|
|
|
|
ConnectInfo.DesktopLength = 0;
|
2013-02-10 13:59:09 +00:00
|
|
|
}
|
|
|
|
|
2014-09-07 22:53:49 +00:00
|
|
|
/* Initialize the Input EXE name */
|
|
|
|
if (ConnectInfo.IsConsoleApp)
|
|
|
|
{
|
|
|
|
LPWSTR CurDir = ConnectInfo.CurDir;
|
|
|
|
LPWSTR AppName = ConnectInfo.AppName;
|
2013-02-10 13:59:09 +00:00
|
|
|
|
2014-09-07 22:53:49 +00:00
|
|
|
InitExeName();
|
2013-02-10 13:59:09 +00:00
|
|
|
|
2014-09-07 22:53:49 +00:00
|
|
|
ConnectInfo.CurDirLength = sizeof(ConnectInfo.CurDir);
|
|
|
|
ConnectInfo.AppNameLength = sizeof(ConnectInfo.AppName);
|
[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
|
|
|
|
2014-09-07 22:53:49 +00:00
|
|
|
SetUpAppName(TRUE,
|
|
|
|
&ConnectInfo.CurDirLength,
|
|
|
|
&CurDir,
|
|
|
|
&ConnectInfo.AppNameLength,
|
|
|
|
&AppName);
|
|
|
|
DPRINT("CurDir = '%S' - AppName = '%S'\n",
|
|
|
|
CurDir, AppName);
|
2013-02-10 13:59:09 +00:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2014-09-07 22:53:49 +00:00
|
|
|
ConnectInfo.CurDirLength = 0;
|
|
|
|
ConnectInfo.AppNameLength = 0;
|
2013-02-10 13:59:09 +00:00
|
|
|
}
|
|
|
|
|
2014-09-07 22:53:49 +00:00
|
|
|
/*
|
|
|
|
* Initialize Console Ctrl Handling, that needs to be supported by
|
|
|
|
* all applications, especially because it is used at shutdown.
|
|
|
|
*/
|
|
|
|
InitializeCtrlHandling();
|
|
|
|
|
2013-02-10 13:59:09 +00:00
|
|
|
/* Connect to the Console Server */
|
2014-09-07 22:53:49 +00:00
|
|
|
if (!ConnectConsole(SessionDir,
|
|
|
|
&ConnectInfo,
|
2014-12-17 22:07:41 +00:00
|
|
|
&InServerProcess))
|
2013-02-10 13:59:09 +00:00
|
|
|
{
|
2014-09-07 22:53:49 +00:00
|
|
|
// DPRINT1("Failed to connect to the Console Server (Status %lx)\n", Status);
|
2013-02-10 13:59:09 +00:00
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
2014-09-07 22:53:49 +00:00
|
|
|
/* If we are not doing server-to-server init and if this is a console app... */
|
2014-12-17 22:07:41 +00:00
|
|
|
if (!InServerProcess && ConnectInfo.IsConsoleApp)
|
2013-02-10 13:59:09 +00:00
|
|
|
{
|
2014-09-07 22:53:49 +00:00
|
|
|
/* ... set the handles that we got */
|
|
|
|
if (Parameters->ConsoleHandle == NULL)
|
|
|
|
SetUpHandles(&ConnectInfo.ConsoleStartInfo);
|
|
|
|
|
|
|
|
InputWaitHandle = ConnectInfo.ConsoleStartInfo.InputWaitHandle;
|
2014-09-09 21:24:44 +00:00
|
|
|
|
|
|
|
/* Sets the current console locale for this thread */
|
2014-09-07 22:53:49 +00:00
|
|
|
SetTEBLangID(lcid);
|
2013-02-10 13:59:09 +00:00
|
|
|
}
|
|
|
|
|
2014-09-07 22:53:49 +00:00
|
|
|
DPRINT("Console setup: 0x%p, 0x%p, 0x%p, 0x%p\n",
|
|
|
|
Parameters->ConsoleHandle,
|
|
|
|
Parameters->StandardInput,
|
|
|
|
Parameters->StandardOutput,
|
|
|
|
Parameters->StandardError);
|
2013-02-10 13:59:09 +00:00
|
|
|
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* EOF */
|