- MSGINA: The `pMprNotifyInfo` and `pProfile` structures returned by
`WlxLoggedOutSAS()`, as well as all of their pointer fields, are
allocated by `LocalAlloc()`[^1][^2]. This is what Windows' Winlogon
expects (and ours too, for interoperability with GINA dlls written
for Windows), as it then frees them using `LocalFree()`.
- WINLOGON: In `HandleLogon()`, free the cached `MprNotifyInfo` and
`Profile` buffers (and all their members) obtained from a previous
call to `WlxLoggedOutSAS()`.
[^1]: https://learn.microsoft.com/en-us/windows/win32/api/winwlx/nf-winwlx-wlxloggedoutsas
[^2]: 3rd-party GINAs rely on this as well. One example can be found at:
https://www.codeproject.com/Articles/20656/Winlogon-using-Mobile-Disk
CORE-18351 CORE-18237 CORE-17137 CORE-16567
CORE-15360 CORE-5071 CORE-3804
Reset `LogonState` back to `STATE_LOGGED_OFF` before invoking
`WlxDisplaySASNotice()` when:
- in `STATE_LOGGED_OFF_SAS` state, `HandleLogon()` failed;
- or when an attempted shutdown operation failed.
This fixes the resulting inconsistent `LogonState` that happened if
any of these operations failed due to legitimate reasons. For example,
a corrupted user profile that caused the login attempt to abort, or,
an ongoing shutdown attempt being aborted as well.
One of the user-visible effects of this inconsistency, was the inability
to access the familiar Logged-Out SAS dialog by pressing Ctrl-Alt-Del at
the invite (SAS notice) dialog, because the `LogonState` was incorrectly
left into the `STATE_LOGGED_OFF_SAS` state, instead of being reset to
`STATE_LOGGED_OFF`.
----
Typical scenario:
The "Administrator" user, who is auto-logged-in by default after the
installation, gets a corrupted ntuser.dat profile registry hive if the
2nd-stage installation is aborted at the end by force-restarting ReactOS.
After reboot, ReactOS tries to log into the account, but fails, and goes
back to the Ctrl-Alt-Del invite dialog.
Before this fix, the user couldn't go into the Logged-Out SAS dialog to
enter new login credentials and attempt login to another account.
This is now fixed.
- Locking (`WLX_SAS_ACTION_LOCK_WKSTA`) is allowed only if `LogonState`
is either `STATE_LOGGED_ON` or `STATE_LOGGED_ON_SAS`, i.e., either the
user invokes the `user32:LockWorkStation()` API or presses Win-L, or,
opens the Logged-On SAS dialog then clicks on the "Lock Workstation" button.
- Unlocking (`WLX_SAS_ACTION_UNLOCK_WKSTA`) is allowed only if
`LogonState` is either `STATE_LOCKED` or `STATE_LOCKED_SAS`,
i.e., the workstation is locked and we are either on the Locked-
notice or on the SAS dialog that asks for the user credentials.
Additionally:
- Fix the invocation order of `LockHandler`/`UnlockHandler` notifications:
* the `LockHandler` is invoked on the Winlogon desktop, just before
displaying the Locked-notice dialog;
* the `UnlockHandler` is invoked on the Winlogon desktop, just before
switching back to the user's desktop.
- If we are on the Logged-On SAS dialog and the user presses Win-L to
lock the workstation (instead of pressing the corresponding dialog
button), the `DoGenericAction(WLX_SAS_ACTION_LOCK_WKSTA)` handler is
invoked asynchronously while the SAS dialog is still being displayed.
We thus need to ensure all the existing dialogs are closed before
displaying the Locked-notice dialog, in order to avoid stray dialogs
being shown concurrently.
CORE-13478
Addendum to commit 46dcab7ab.
The `WLX_SAS_ACTION_TASKLIST` action can be invoked in three scenarii to
open the Task-Manager:
1. from the logged-on state (`LogonState == STATE_LOGGED_ON`), when the
user presses Ctrl-Shift-Esc while being on its own desktop (usual case);
2. from the Logged-On SAS dialog (`LogonState == STATE_LOGGED_ON_SAS`),
when the user presses the "Task-Manager" button: here Winlogon should
switch back to the user's desktop, restoring `STATE_LOGGED_ON` and
start the TaskMgr;
3. or when the user presses Ctrl-Shift-Esc **while being on the Logged-On
SAS dialog**: in this case, the Task-Manager is started on the
currently-hidden user's desktop (and so, will be hidden), but the SAS
dialog stays open. The user will see the opened TaskMgr once (s)he
closes the SAS dialog and Winlogon switches back to the user's desktop.
In order to support these scenarii, the `WLX_SAS_ACTION_TASKLIST` action
handling is reworked:
- `SASWindowProc(WM_HOTKEY, IDHK_CTRL_SHIFT_ESC)` always invokes the
`DoGenericAction(WLX_SAS_ACTION_TASKLIST)`: this allows centralizing
inside `DoGenericAction()` the condition checks for starting TaskMgr.
- `DoGenericAction(WLX_SAS_ACTION_TASKLIST)` just starts the Task-Manager
only if the Winlogon's `LogonState` is either `STATE_LOGGED_ON` or
`STATE_LOGGED_ON_SAS`. It doesn't attempt there to switch desktops nor
change the `LogonState` value, in order to support scenarii 2 and 3.
- The switch from/to Winlogon/user's desktops when going to the
`LogonState: STATE_LOGGED_ON -> STATE_LOGGED_ON_SAS` change is done
in `DispatchSAS()`, just before invoking the GINA's `WlxLoggedOnSAS()`
(see below for more details) and just after it returns, only in the
necessary cases.
----
[MSGINA] The WlxLoggedOnSAS() dialog shouldn't switch the desktops itself.
This behaviour can be observed on Windows with Winlogon debugging + tracing
enabled. It is Winlogon instead that does the desktop switch itself, as for
all the other SAS dialogs, in addition to changing its internal `LogonState`.
Fix for commit 7aecedf79 (r58785).
CORE-18958
Introduce an emergency log-off and restart feature, available when holding
down the control key and selecting "Log Off" or "Shut down" in the MSGINA
Ctrl-Alt-Del security dialog, similar to Windows Server 2003 and newer
Windows versions.
This includes:
- Notification dll calling in CallNotificationDll().
- winmm.dll API calling (e.g. PlaySound) in PlaySoundRoutine().
Also:
- Fix dwKeyName usage in RegEnumKeyExW() specifying a number of *characters*.
Refactor the security related code of Winlogon and move it to its own dedicated place, security.c. This includes code for preparation of security descriptors for window station and desktop objects when their created, helper functions which give allow access to such objects for the logged in user and whatnot.
==== DO NOTE ====
Currently new desktop security assignment fails because for whatever reason the system thinks the application desktop has no prior security even though a descriptor has been created for it before. See the FIXME comment on code for information.
This avoids keeping connections open and reopening them as soon
as the user reopens their session.
This fixes network shared being duplicated each time session
is reopened.
CORE-15012
