As of now the Object Manager private service, ObpCloseHandleTableEntry, looks for OBJ_PROTECT_CLOSE attribute if a handle should not be closed. However, in ObDuplicateObject if an attribute of OBJ_PROTECT_CLOSE is found as it's been filled to the caller (see L2466) this attribute is removed from the attributes list of the new handle and ObpAccessProtectCloseBit access is granted to the newly duplicated object handle.
With that being said ObpCloseHandleTableEntry indiscriminately closes the object handle albeit it shouldn't do so. As a matter of fact in Windows Server 2003 SP2 this service indeed checks for ObpAccessProtectCloseBit flag bit and if the condition is met then it returns STATUS_HANDLE_NOT_CLOSABLE as it should. Therefore we should do the same.
Now NtClose can properly warn the calling thread the object handle can't be closed which fixes a testcase failure within NtDuplicateObject NTDLL APITEST where this function gives handle close protection bit as requested by the caller.
Thanks goes to I_Kill_Bugs for the patch (and partly to Kyle Katarn for the PR) and Hermes for tweaking the patch code. Had to make a commit myself as the PR author's account is deleted.
Signed-off by: I_Kill_Bugs (original patch author)
Signed-off by: Kyle Katarn <contact@kcsoftwares.com>
Signed-off by: Hermès BÉLUSCA - MAÏTO <hermes.belusca-maito@reactos.org>
Implement FC (file comparison) command. As a starting point, we support binary mode comparison at first. Text mode comparison and wildcard are not supported yet. CORE-17500
Do a sanity check onto the dialog box type before terminating it. As it stands now, a call of PostQuitMessage() is invoked even when the dialog box is modal. This is illegal due to the fact that the shutdown dialog box is initiated by the "Security" main window thus WlxDialogBoxParam.
A call to PostQuitMessage onto a modal dialog box leads to a undefined behaviour, as it'll not just terminate the thread but also eventually killing the Winlogon process whose the thread belongs to.
CORE-17535
According to RFC 3927, the pseudo-random number generation algorithm MUST be chosen
so that different hosts do not generate the same sequence of numbers, and that the
pseudo-random number generator SHOULD be seeded using a value derived from the
IEEE 802 MAC address, so that a host will usually select the same IPv4 Link-Local
address each time it is booted.
* Guard the token in a lock whilst querying stuff
* Remove the piece of code that checks if the information class provided is above the maximum information class threshold. That code literally duplicates the inner functionality of the default case in the switch block, where the code falls in that case if an invalid information class is provided anyway.
* Remove the redundant information classes. Internally, this function in Windows has 12 switch case blocks (11 token info classes + the default case) and the other classes are supported in NtQueryInformationToken only so it doesn't make any logical sense to keep them in the codebase.
* Annotate the argument parameters with SAL and add documentation header
Having conditional statements with CMAKE_BUILD_TYPE is an antipattern
See https://stackoverflow.com/questions/66079007/having-conditional-statements-on-build-type-variable-a-good-design
We use both single- and multi-config generators (Ninja and VS), so we
can't really rely on CMAKE_BUILD_TYPE, because it's not always set.
This commit alters some conditional flags to use <$CONFIG:...>
generator expression, but is still not complete. Also, our default
optimization level (4) now has what was always a de-facto flags
config*.cmake files are constantly getting out of sync between
each other. Besides that, the parameters are not really dependent
on a target architecture, but rather on a compiler (except *ARCH)
This approach seems to be more future-prone, and allows to see
all the options in one file (there are really not that many of them)
