- partial Wine sync, fixes crashing shlfileop winetest:
Use the current directory when copying to an empty destination.
Fix a memory leak in SHFileOperationW.
Vincent Povirk <vincent at codeweavers dot com>
svn path=/trunk/; revision=46098
- For any device that actually had resources we would return STATUS_SUCCESS without building a resource list and if the device didn't have resources we would end up freeing a NULL pointer, storing stack trash in Irp->IoStatus.Information, and then returning STATUS_SUCCESS
- Fixes reporting device resources (and possibly the VBox additions crash with ACPI enabled)
svn path=/trunk/; revision=46080
- Actually store the IO_RESOURCE_REQUIREMENTS_LIST in Irp->IoStatus.Information in response to IRP_MN_QUERY_RESOURCE_REQUIREMENTS so the PnP manager can use it (and fixes another memory leak)
svn path=/trunk/; revision=46073
Theres more, like: comctl32, comdlg32, oleaut32, riched20, sti, version, winemp3.acm, wininet and winhttp which is above my skills or looks strange, like its not really synched (winemp3.acm!!) Feel free to play with them.
svn path=/trunk/; revision=46072
Additionally I added a * to all Autosyncs which lie a bit back already. Will look through them and check which are still recent.
svn path=/trunk/; revision=46058
[CSRSRV]: Mostly moved all the current CSRSS code into CSRSRV, with some very minor changes to get it workking.
[CSRSRV]: Add some more code from Alex's CSRSRV, such as thread dereferencing/deallocation, hacked to work.
[CSRSRV]: Make CsrTerminateProcess destroy each CSR thread in that process, otherwise we were always leaking a handle, so processes never died. Because of this, primary tokens would remain "in use", and when umpnpmgr attempted to do a "Create Process as User" for the second+ time, the call would fail since the token from the first process was still around. This fixed that regression from the mailing list.
svn path=/trunk/; revision=46051
[CSRSS]: Bang in the new thread support in a bunch of places, including creating static server threads. It's very hacked and handle duplication doesn't work 100% reliably, but it gets the job done.
[CSRSS]: Add CsrGetProcessLuid, CsrImpersonateClient, CsrRevertToSelf, CsrShutdownProcesses, CsrFindProcessForShutdown required for user-mode shutdown. Right now we are able to reliably enumerate user apps (in the user LUID) and then service/system apps (in the LOCAL SYSTEM LUID).
svn path=/trunk/; revision=46042
Add French translation.
Add battery.inf and fdc.inf to syssetup process.
Floppy disk controllers and batteries now appear correctly in device manager.
Dedicated to aicom ;)
svn path=/trunk/; revision=46038
Impersonation failed because NtImpersonateThread was actually inverting the THREAD_IMPERSONATE rights, asking the client thread for the server's permissions, and vice versa. Fixing this resulted in yet another failure.
Analysis of this failure showed that even opening the server (ie: current) thread for THREAD_DIRECT_IMPERSONATION failed, which is unusual since the current thread should have access to all its rights. This is determined in PspCreateThread when the ETHREAD->GrantedAccess field is set.
Continuing onto this path, tracing revealed that GrantedAccess was merely 0x1607F and not 0x1F3FF as expected, meaning that not all rights were given, including the impersonate right (0x200), explaining the failure, but not the deeper reason behind it.
Attempting to identify which code path set this GrantedAccess, the SepAccessCheck routine came to light. A bug there caused MAXIMUM_ALLOWED accesses to fail in certain scenarios, such as when the object had no security descriptor, because MAXIMUM_ALLOWED would be granted as an absolute value, when instead of it is a flag that should grant GENERIC_ALL. Fixing that bug, the failure continued.
Further analysis identified that the Administrators SID was being found with GENERIC_READ + WRITE + EXECUTE access, and no SID was found for GENERIC_ALL access. This happened when searching the system token's default DACL, which is assigned to the kernel (but for kernel-mode callers, this check was skipped), smss, winlogon, etc.
The code for creating this system token was heavily hacked, so the function to create the system token, as well as NtCreateToken were refactored to use a common piece of token-creating code. Furthermode, the system token was correctly created with Local System as the user, and Administrators as one of the groups. Finally, SeDefaultDacl was used (already setup properly) instead of a badly configured Default DACL. The new shared code also correctly sets the SE_GROUP_ENABLED flag on all SE_GROUP_MANDATORY groups, and scans tokens to set the TOKEN_HAS_ADMIN_GROUP and TOKEN_HAS_TRAVERSE_PRIVILEGE flags which were not previously set.
With the correct system token and default DACL, the Local System SID was now found, but the failure continued. This was revealed to be due to an even deeper rooted problem, as the SepIsSidInToken routine checked for SE_GROUP_ENABLED before listing a SID as "present". Although this is correct for actual groups, the User SID will never have the SE_GROUP_ENABLED flag as it is not a group. This caused any granted access ACE belonging to a user (instead of a group) to be ignored, causing either access check failures, or limited rights returned (in the MAXIMUM_ALLOWED case).
Upon fixing this bug, the NtImpersonateThread call finally returned success, since the rights were now correct. Promptly upon calling NtOpenThreadToken to query the LUID however, the system ASSERTED with FALSE.
The code at fault was a line in NtOpenThreadTokenEx which forcefully ASSERTed if the impersonation code path was taken, presumably because this was never tested, and ReactOS would actually always fail impersonation attempts due to the bugs fixed above. This routine was thus quickly reworked to fix some mistakes (such as forgetting to actually impersonate the client, incorrect referencing/dereferencing of thread/tokens, and assumptions about DACL creation success).
Having fixed the NtOpenThreadTokenEx routine, the LUID query now went through for the impersonated token, but soon causing a user-mode crash, due to an incorrect parameter reference in the CsrGetProcessLuid function in the csrsrv code by Alex (which I copy/pasted to reduce code duplication).
Fixing this final bug finally allowed the correct LUID to be queried and I was able to continue development of not-yet-commited user-mode shutdown code.
svn path=/trunk/; revision=46028
