Зачем создается отдельный процесс winlogon.exe для каждого залогиненного пользователя.
Ведь процесс winlogon.exe работает под аккаунтом SYSTEM поэтому имеет доступ к любым объектам ???

Здравствуйте, Аноним, Вы писали:

А>Зачем создается отдельный процесс winlogon.exe для каждого залогиненного пользователя.
А>Ведь процесс winlogon.exe работает под аккаунтом SYSTEM поэтому имеет доступ к любым объектам ???

Собственно кто из них отображает десктоп входа в систему ?

Здравствуйте, Аноним, Вы писали:

http://www.kaspersky.ru/kaspersky_anti-virus
http://www.symantec.com/norton/antivirus
http://us.mcafee.com/
http://www.esetnod32.ru/

А>Зачем создается отдельный процесс winlogon.exe для каждого залогиненного пользователя.
А>Ведь процесс winlogon.exe работает под аккаунтом SYSTEM поэтому имеет доступ к любым объектам ???
Потому что каждый пользователь работает в своей win32 сессии.
А процесс может иметь доступ к win32 объектов только той одной сессии в которой он работает. И менять ее по своему желанию он не может.

Здравствуйте, Аноним, Вы писали:

А>>Зачем создается отдельный процесс winlogon.exe для каждого залогиненного пользователя.
А>>Ведь процесс winlogon.exe работает под аккаунтом SYSTEM поэтому имеет доступ к любым объектам ???
А>Потому что каждый пользователь работает в своей win32 сессии.
А>А процесс может иметь доступ к win32 объектов только той одной сессии в которой он работает. И менять ее по своему желанию он не может.

Может ли процесс из сессии 1 передать handle десктопа например процессу из сессии 2 ?

А>Может ли процесс из сессии 1 передать handle десктопа например процессу из сессии 2 ?
Десктоп — это объект win32k подсистемы. Его не существует вне его "родной" сессии. И обратиться к нему извне низззя. Вообще. Никак. В каждой сессии — загружена своя копия win32k.sys, у каждой — своя отдельная память сессии в пространтсве ядра и у каждой понятное дело — свои объекты.

А>>Может ли процесс из сессии 1 передать handle десктопа например процессу из сессии 2 ?
А>Десктоп — это объект win32k подсистемы. Его не существует вне его "родной" сессии. И обратиться к нему извне низззя. Вообще. Никак. В каждой сессии — загружена своя копия win32k.sys, у каждой — своя отдельная память сессии в пространтсве ядра и у каждой понятное дело — свои объекты.
Насчет памяти поясню — в пространстве ядра есть диапазон виртуальных адресов тн session space в который и грузиться win32k. Процесс одной сессии не может обратиться к session space другой сессии, и понятное дело, никак не может дотянуться до ее объектов. Виртуальная память однако, просто мапиться на разные физ страницы. Совсем как в юзермодных процессах
По сути так изначально и было — изначально win32 и была отдельным процессов, потом citrix разработал терминальный сервер под винду, похука все и вся и запустив пачку win32 процессов на одной системе. Его у них быстренько лицензировал микрософт (терминальные серверы это же огромный источник бабла!) и быстренько впендюрил win32 с лицензированным у цитрикса функционалом (поищите по п??жженым исходникам венды слово Citrix) в ядро, сказав что "так будет быстрее работать". Впендюрили в ядро абы как, чего только стоит отращивание ядреного стека у потоков при попытке обратиться к win32k сервисам и куча секурити дыр которые в 2000й попытались залатать на скорую руку job'ами, на которые потом забили А в висте изобрели UAC, скрутив переизобретенный функционал сырых на данный момент job'ов (аля разграничения доступа к win32k объектам в сессии) + CreateRestrictedToken, добавили к этому модное окошечко с кнопками Allow/Deny, и добавили в токен новую сущность, соединяющую это воедино (IL). Ох чета меня понесло, спать пора...

А>Может ли процесс из сессии 1 передать handle десктопа например процессу из сессии 2 ?

Да. Воспользуйся функцией DuplicateHandle(). Она создаст новый хендл на тот же самый объект (десктоп), но уже в таблице хендлов второго процесса. Значение нового хендла затем достаточно каким-либо образом передать второму процессу (например, через пайпы).

Здравствуйте, x64, Вы писали:

А>>Может ли процесс из сессии 1 передать handle десктопа например процессу из сессии 2 ?

x64>Да. Воспользуйся функцией DuplicateHandle(). Она создаст новый хендл на тот же самый объект (десктоп), но уже в таблице хендлов второго процесса. Значение нового хендла затем достаточно каким-либо образом передать второму процессу (например, через пайпы).

Еще вопрос по этой теме:
Что же тогда вернет OpenInputDesktop() если десктоп который получает ввод принадлежит другой сессии ?

M>Что же тогда вернет OpenInputDesktop() если десктоп который получает ввод принадлежит другой сессии ?

Как что? Хендл десктопа. И не важно из какого сеанса ты будешь её вызывать. Кстати, вдогонку: для того, чтобы создать копию хендла в процесс в другом сеансе, тебе понадобятся привилегии отладки. Включить их можно с помощью вот такой функции:

bool
EnableDebugPrivilege ()
{
    bool bResult = false;
    DWORD dwRetLen = 0;
    HANDLE hToken = NULL;
    TOKEN_PRIVILEGES tp = {0};
    LUID luid = {0};

    if (! OpenProcessToken (
        GetCurrentProcess (),
        TOKEN_ADJUST_PRIVILEGES | TOKEN_QUERY,
        &hToken))
    {
        goto Cleanup;
    }

    if (! LookupPrivilegeValue (
        NULL,
        SE_DEBUG_NAME,
        &luid))
    {
        goto Cleanup;
    }

    tp.PrivilegeCount = 1; 
    tp.Privileges [0].Luid = luid;
    tp.Privileges [0].Attributes = SE_PRIVILEGE_ENABLED;

    if (! AdjustTokenPrivileges (
        hToken,
        FALSE,
        &tp,
        sizeof (TOKEN_PRIVILEGES),
        NULL,
        &dwRetLen))
    {
        goto Cleanup;
    }

    bResult = true;

Cleanup:

    if (hToken) CloseHandle (hToken);

    return bResult;
}

x64>Да. Воспользуйся функцией DuplicateHandle(). Она создаст новый хендл на тот же самый объект (десктоп), но уже в таблице хендлов второго процесса. Значение нового хендла затем достаточно каким-либо образом передать второму процессу (например, через пайпы).
Видители, формально DuplicateHandle сработает, и в таблице хэндлов он конечно появиться. NT сделает свое дело исправно.
А вот заюзать хэндл тот процесс — не сможет, если он работает в другой сессии.

x64>>Да. Воспользуйся функцией DuplicateHandle(). Она создаст новый хендл на тот же самый объект (десктоп), но уже в таблице хендлов второго процесса. Значение нового хендла затем достаточно каким-либо образом передать второму процессу (например, через пайпы).
А>Видители, формально DuplicateHandle сработает, и в таблице хэндлов он конечно появиться. NT сделает свое дело исправно.
А>А вот заюзать хэндл тот процесс — не сможет, если он работает в другой сессии.
Поясню чтоб вы поэкспериментировав, не начали ломать голову почему и как оно работает:
CreateDesktop создает в таблице хэндлов хэндл на объект-заглушку. В котором есть несколько полей. Одно из них — ID сессии которой принадлежит объект, другое — указатель на win32k объект валидный _только_ в той сессии в которой он создан. И первое что делает какая нить NtUserSetThreadDesktop или NtUserBuildHwndList — проверяют что ID сессии совпадает с ID сессии текущего процесса, и посылают нах со статусом STATUS_INVALID_HANDLE если сессии разные. И правильно делают. Т.к. указатель на реальный объект в другой сессии — просто мусорный поинтер.

Здравствуйте, x64, Вы писали:

M>>Что же тогда вернет OpenInputDesktop() если десктоп который получает ввод принадлежит другой сессии ?

x64>Как что? Хендл десктопа. И не важно из какого сеанса ты будешь её вызывать. Кстати, вдогонку: для того, чтобы создать копию хендла в процесс в другом сеансе, тебе понадобятся привилегии отладки. Включить их можно с помощью вот такой функции:

Я вызываю ф-цию OpenInputDesktop() из сервиса под Вистой.
Имя возвращенного десктопа ="Default", даже когда "WinLogon" десктоп явно активен. разрешения десктопа сессии 0 1024х768, тогда как в сессии 1 разрешение 1280х1024.

По этим экспериментам я сделал вывод что, OpenInputDesktop() всегда возвращает хенд десктопа из текущей сессии.

Или вы уверены что я не прав, и мне стоит повторить мой эксперемент ???

А>Или вы уверены что я не прав, и мне стоит повторить мой эксперемент ???

Я не знаю, правы вы или нет, но думаю стоит повторить эксперимент, учитывая вот это:

OpenInputDesktop

The calling process must have an associated window station, either assigned by the system at process creation time or set by SetProcessWindowStation. The window station associated with the calling process must be capable of receiving input.

Для сильно улфбчивых процитирую общеизвестные сорсы:

BOOL NtUserSetThreadDesktop(
    IN HDESK hdesk)
{
    PDESKTOP pdesk = NULL;
    NTSTATUS Status = STATUS_SUCCESS;

    BEGINRECV(BOOL, FALSE);
    Status = ValidateHdesk(hdesk, UserMode, 0, &pdesk);
    if (NT_SUCCESS(Status)) {
        retval = xxxSetThreadDesktop(hdesk, pdesk);
        LogDesktop(pdesk, LD_DEREF_VALIDATE_HDESK1, FALSE, (ULONG_PTR)PtiCurrent());
        ObDereferenceObject(pdesk);
    } else if (hdesk == NULL && PsGetCurrentProcess() == gpepCSRSS) {
        retval = xxxSetThreadDesktop(NULL, NULL);
    } else
        retval = FALSE;

    TRACE("NtUserSetThreadDesktop");
    ENDRECV();
}
...
NTSTATUS ValidateHdesk(
    HDESK           hdesk,
    KPROCESSOR_MODE AccessMode,
    ACCESS_MASK     amDesired,
    PDESKTOP*       ppdesk)
{
    NTSTATUS Status;

    Status = ObReferenceObjectByHandle(
            hdesk,
            amDesired,
            *ExDesktopObjectType,
            AccessMode,
            ppdesk,
            NULL);

    if (NT_SUCCESS(Status)) {

        if ((*ppdesk)->dwSessionId != gSessionId) {

            RIPNTERR3(STATUS_INVALID_HANDLE, RIP_WARNING,
                      "SessionId %d. Wrong session id %d for pdesk %#p",
                      gSessionId, (*ppdesk)->dwSessionId, *ppdesk);

            goto Error;
        }

        LogDesktop(*ppdesk, LDL_VALIDATE_HDESK, TRUE, (ULONG_PTR)PtiCurrent());

        if ((*ppdesk)->dwDTFlags & (DF_DESTROYED | DF_DESKWNDDESTROYED | DF_DYING)) {
            RIPNTERR1(STATUS_INVALID_HANDLE, RIP_ERROR,
                      "ValidateHdesk: destroyed desktop %#p",
                      *ppdesk);
Error:
            ObDereferenceObject(*ppdesk);
#if DBG
            *ppdesk = NULL;
#endif // DBG

            return STATUS_INVALID_HANDLE;
        }
    } else {
        RIPNTERR1(Status, RIP_VERBOSE, "ValidateHdesk failed for %#p", hdesk);
    }

    return Status;
}

good luck