Unable to drag/drop a file to terminal with UAC turned off

[d0j]

Windows Terminal version (or Windows build number)

Windows [Version 10.0.22000.282] Terminal [Version 1.12.2931.0]

Other Software

None open at the time

Steps to reproduce

Run windows terminal as administrator.
Try to drag a file/folder into the terminal to copy its path to the terminal window.
Does not work.

Expected Behavior

I expected drag and drop for files/folders into the terminal window to behave the same as a command prompt or powershell window, both behave as expected in non-admin or administrator permission instances of the aforementioned programs.

Actual Behavior

Path does not get copied during drag and drop into the terminal window, I just get the "deny" "not allowed" cursor icon when trying, same problem as #7754 but ticket closed

[zadjii-msft]

To be very specific - Are you running the Terminal as your local user account, but with admin permissions, or do you have UAC disabled entirely? These are two similar sounding but totally different scenarios unfortunately.

[d0j]

To be very specific - Are you running the Terminal as your local user account, but with admin permissions, or do you have UAC disabled entirely? These are two similar sounding but totally different scenarios unfortunately.

UAC is disabled.
I am working under an administrator account.

[zadjii-msft]

To be totally sure I'm doing this right - what's the output of reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\ /v enablelua?

[d0j]

To be totally sure I'm doing this right - what's the output of reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\ /v enablelua?

`reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\ /v enablelua

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
enablelua REG_DWORD 0x0`

[zadjii-msft]

Huh okay, that's the situation that I thought I fixed. Weird.

[eryksun]

I can confirm that it isn't fixed in 1.12.2931.0. I disabled UAC and logged on with an administrator account. I verified that the access token of Explorer in this case has high mandatory integrity level and has the administrators group enabled, the same as Terminal.

[eryksun]

IMO, IsElevated() from GH-11221 is badly named. The name is misleading because the function returns false for default elevation. It also checks for administrator access, which is separate from the token's elevation level. It should be named something descriptive like IsUserALinkedAdmin().

For the elevation check, it only needs to check for the elevation type TokenElevationTypeFull, which implies that the token is an elevated token that's linked to a limited token.

The function also has a technical bug, but one that's not an issue currently. Using nullptr for the token passed to test_token_membership() uses the effective token of the current thread in the underlying CheckTokenMembership() call. But the elevation check explicitly uses the process token, i.e. GetCurrentProcessToken() (i.e. (HANDLE)(LONG_PTR)-4). For the effective token, use GetCurrentThreadEffectiveToken() (i.e. (HANDLE)(LONG_PTR)-6), which references the thread token, if the thread is impersonating, else the process token. A name like IsUserALinkedAdmin() implies it should be checking the process token in both cases. I don't think Terminal ever impersonates another user, so there's no need to worry about effective access. BTW, closing these pseudohandles is a wasted system call that does nothing. There's no need for RAII.

[DHowett]

FWIW I believe that the implementation in IsElevated as of 1.12 does the wrong thing as well, but in a different direction.

[zadjii-msft]

Huh, so observation: I don't think we can fix this currently. Seems like the OS straight up disables XAML drag/drop when EnableLUA is set to 0. I'm trying it out with Sticky Notes in a VM, and that's not letting me drag/drop anything into it. I don't think the TermControl is doing anything to suppress the Drag event - it doesn't reject drops when it's elevated:

terminal/src/cascadia/TerminalControl/TermControl.cpp

Lines 2373 to 2392 in a766798

	void TermControl::_DragOverHandler(Windows::Foundation::IInspectable const& /*sender*/,
	DragEventArgs const& e)
	{
	if (_IsClosing())
	{
	return;
	}
	// We can only handle drag/dropping StorageItems (files) and plain Text
	// currently. If the format on the clipboard is anything else, returning
	// early here will prevent the drag/drop from doing anything.
	if (!(e.DataView().Contains(StandardDataFormats::StorageItems()) ||
	e.DataView().Contains(StandardDataFormats::Text())))
	{
	return;
	}
	// Make sure to set the AcceptedOperation, so that we can later receive the path in the Drop event
	e.AcceptedOperation(DataPackageOperation::Copy);

[zadjii-msft]

MSFT:35616520 has more context here. Looks like this is going to be an unfortunate "no" for now. We may need to move to a future version of WinAppSDK that might support this, whenever support for elevated drag/drop is added to WASDK.

[DHowett]

Wow, I really don't know what I meant when I said that "1.12 had it wrong in the opposite direction" -- the code is the same, as far as I can tell.

The core issue that prevents tab reordering is that we have a process, DataExchangeHost, that is used to render the bitmap attached to the cursor and shuttle data into the receiving process. That process must be running as the same user and at the same IL (I think¹) as Terminal.

The two cases where it isn't running as the same user or at the same IL are:

1. Linked token?
2. Over-the-shoulder elevation. This might secretly work (?) because of how brokering works.

Since we can't detect the identity of the DataExchangeHost, we had to solve for a heuristic . . . so IsElevated was originally designed to handle (1) because we needed to use it to disable drag/drop in case (1).

It was probably a mistake to try to generalize it and use it for anything else -- and we may want to rectify that mistake.

However, the issue IN THIS THREAD is different. Terminal doesn't directly control what external applications can drag/drop to it -- this is just a platform limitation. We'll need to take it up internally.

¹ Since it's just COM, and it doesn't want to "punch down" at a lower-IL process. I think.

[zadjii-msft]

Oh hey this is actually tracked elsewhere: /dup #6661

[ghost]

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

[he852100]

@zadjii-msft They are two different problems

[a657938016]

@zadjii-毫秒它们是两个不同的问题

麻烦问下你的这个问题解决了吗？我也遇到同样的问题

[Sincky]

it still not work in version 1.15.3465.0 when UAC disable and reg query with "enablelua REG_DWORD 0x0"