locked
Drag n' Drop files in Vista RC1? RRS feed

  • Question

  • Dear all,

    I find a very strange issue in Vista RC1.

    If we wanna add "requireAdministrator" in the program,

    (Ref http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnlong/html/AccProtVista.asp)

    The program will still fail to get the "WM_DROPFILES" message from Vista.

    Does anyone have the same problem?...Orz

    Best Regards,

    Shuyang

    p.s. The following is my manifest

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
    <assemblyIdentity
        version="1.0.0.0"
        processorArchitecture="X86"
        name="Microsoft.Windows.XPStyle"
        type="win32"
    />
    <description>Your app description here</description>
    <dependency>
        <dependentAssembly>
            <assemblyIdentity
                type="win32"
                name="Microsoft.Windows.Common-Controls"
                version="6.0.0.0"
                processorArchitecture="X86"
                publicKeyToken="6595b64144ccf1df"
                language="*"
            />
        </dependentAssembly>
    </dependency>
      <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
        <security>
          <requestedPrivileges>
            <requestedExecutionLevel
              level="requireAdministrator"
              uiAccess="false"/>
            </requestedPrivileges>
           </security>
      </trustInfo>
    </assembly>

    Monday, September 18, 2006 7:14 AM

All replies

  • For security reasons, drag/drop is disallowed between windows with different security level.
    Friday, September 22, 2006 6:11 PM
  • Dear Raymond,

    My application needs "Drag n' Drop" and "Write registry key into HKEY_CLASSES_ROOT"

    I've tried "requireAdministrator" and "highestAvailable" in the manifest.xml for registry key writing

    But they would both disallow the "Drag n' Drop" function.

    Is there a way to allow "Drag n' Drop" and "Write registry key into HKEY_CLASSES_ROOT" in the application?

    Best regards,

    Shuyang

    Tuesday, September 26, 2006 2:36 AM
  • You can use your imagination. For example, have two processes, one that does the UI and accepts the drag/drop, and another that does the HKCR stuff. But generally speaking applications should not be messing with HKCR at runtime; they should only update it at install time.
    Tuesday, September 26, 2006 2:40 AM
  • Dear Raymond,

    It seems that WM_COPYDATDA does not work on the "requireAdministrator" program.

    (Please ref to the topic WM_COPYDATA and manifest.xml)

    I try to use "Event" to let two programs communicate each other.

    The Event is created in the "requireAdministrator" program and the other program without "requireAdministrator" would signal it.

    However, I find out that the program without "requireAdministrator" can not signal the event which is created by the "requireAdministrator" program.

    This design only works when the event is created in the program without "requireAdministrator".

    Does it the right behavior or it will be fixed in the future version of Vista?

    Best regards,

    Shuyang

    Monday, October 9, 2006 10:28 AM
  • This is expected. When the high-privilege process creates the event, the default security attributes permit only other high-privilege processes to access it. If you want a lower-privilege process to be able to access the event, you need to set custom security on the event.
    Monday, October 9, 2006 4:40 PM
  • Hi,

    I am having the same issue. How do you custom set the security of the event?

    Thanks

    Tuesday, October 10, 2006 3:05 AM
  • Use the LPSECURITY_ATTRIBUTES parameter of CreateEvent to set custom security on an event. Note that this is not for the faint of heart. If you mess up, you can create a security hole. (The same security hole that the default security attributes are trying to protect you from.)
    Tuesday, October 10, 2006 3:09 AM
  • Can you please show and example of this?
    Tuesday, October 10, 2006 11:12 PM
  • Lots of other people have written ACL-management code. Here are some (I do not vouch for their accuracy; these are just the first few that came up in a web search)

     http://www.codeproject.com/win32/accesscontrollists.asp

    http://www.codeproject.com/system/secntobj.asp

    Wednesday, October 11, 2006 12:08 AM
  • Can I disable this "feature" (I can't drag files from explorer to Visual Studio 2005): this single fault alone is seriously making me consider ditching Vista and switching back to XP on my software development machine.

    Friday, March 16, 2007 7:32 AM
  • I'm with you on that.

     

    Monday, March 19, 2007 9:40 PM
  • I'm working around the issue by creating a desktop shortcut to "explorer.exe" and setting "Run as administrator" under "Advanced Properties" and adding a shortcut key to make it easier to bring up.  Still have that annoying "User Account Control" dialog though...  Stick out tongue

    Wednesday, April 4, 2007 11:53 PM
  • No response from microsoft since 2006 huh? 

    I'm banging my head trying to get a simple drag and drop app to work in Vista, including running it as administrator and no luck.

    Very disappointing; one more Vista annoyance.

    -gw
    Tuesday, July 29, 2008 2:34 AM
  •  

    I think you posted your comment to the wrong thread. Drag and drop between applications of similar security works just fine. It's crossing security levels that is blocked -- for security reasons, of course. An application can use the ChangeWindowMessageFilter function to indicate that it wants specific insecure messages to be delivered anyway.
    Tuesday, July 29, 2008 4:35 AM
  • Thanks Raymond.  I am now calling ChangeWindowMessageFilter like this:

        ChangeWindowMessageFilter(WM_DROPFILES, MSGFLT_ADD);

    and it's returning a value of '1' but it still refuses to accept file drops.  Is there something I'm missing?

    -gw

    Tuesday, July 29, 2008 1:44 PM
  •  

    WM_DROPFILES is just the last message in the drag/drop negotiation. You don't want to enable all of the COM messages since they are used for much more than just drag and drop. What you can do is have a helper program that accepts the drop (with the helper program running non-elevated so it can receive all the COM messages, even the dangerous ones), and have the helper window forward the information to the protected window via a specific message.
    Tuesday, July 29, 2008 2:28 PM
  • That solution is unacceptable,   Running a separate application to either be a "drop bucket" or doing something hacky like trying to overlay the primary application is not a good solution for users and spreads out your application providing more surfaces to potential security issues.

    I would like to enable drag-and-drop support of files form the shell, please enumerate all of the messages that would have to be enabled to get drag and drop working for this case.

    On another note, I see that
    Visual Studio 2008 properly paints their drop icon showing that the user can't drop something on the application.  Do they have to "un-filter" some messages to make that work? Or is it something that is handled automatically with their window registration?





    Thursday, July 31, 2008 11:46 PM
  • For what it's worth I totally agree that's not an acceptable solution.

    My solution might not be much better, but it is to disable UAC.  This is the only way I can figure out how to reasonably make drag and drop work in my app. Sad

    -gw
    Friday, August 1, 2008 1:18 AM
  • A better solution overall is to re-architect the application so that it doesn't run elevated all the time and perform COM elevation only if and when absolutely necessary. The vast majority of applications that work in a drag-drop world probably aren't the sort of things that should be running elevated anyway (and yes, I'd include Visual Studio in that).
    Friday, August 1, 2008 12:52 PM
  • Hi all --

     

    Thanks for the crucial information. This thread has taught us much.

     

    Obviously, the best solution is to have your program run under lower privileges, therefore it will accept all messages without a problem. Our program runs fine under "user" privileges (and it does not request elevated privileges), so there shouldn't be a problem. However, our installer must run under administrative privileges, and when it spawns our program for the first time, the new process also follows suit with admin privileges.

     

    According to the thread at the bottom of the CodeProject page http://www.codeproject.com/KB/vista-security/VistaElevator.aspx, there is no API to reduce the privileges of a specific process. The solution for spawning a lower-level process is an ugly hack involving Scheduled Tasks. Likewise, our installer also has an option to fork itself into two separate processes on different elevation levels ... http://nsis.sourceforge.net/UAC_plug-in, but this, too, is an ugly hack.

     

    After a long day, we decided on the "solution": simply to disable launching the process at the end of the installer.

    In short - there is no "nice" solution. We hope to revisit the problem when Microsoft provides the tools necessary to deal with the day-to-day problems that arise while trying to work with UAC.

     

    Thanks for the valuable info.

    Tuesday, August 26, 2008 1:16 PM
  • Hi Eli,

     

    Microsoft has an example for starting a low or medium integrity process from a high integrity process like your installer:

     

    http://msdn.microsoft.com/en-us/library/bb250462.aspx#dse_stlip

    Tuesday, August 26, 2008 6:13 PM
  •  Ellery Pierce wrote:

    Hi Eli,

     

    Microsoft has an example for starting a low or medium integrity process from a high integrity process like your installer:

     

    http://msdn.microsoft.com/en-us/library/bb250462.aspx#dse_stlip

     

    Not quite. Launching a low-integrity process from a medium-integrity one, which will be within the same user context, is very different to launching  a low/medium one from a high integrity process, which can easily be running under a different user's context.

     

    Following the description there from an elevated process can introduce subtle security (and other) bugs into your application.

    Wednesday, August 27, 2008 12:50 PM
  • Here is how to enable drag and drop from a medium integrity process (e.g. Explorer) to a high integrity process (your app):

    http://it-from-inside.blogspot.com/2010/03/how-to-enable-drag-and-drop-for.html

    The trick?

    ChangeWindowMessageFilter (WM_DROPFILES, MSGFLT_ADD);
    ChangeWindowMessageFilter (WM_COPYDATA, MSGFLT_ADD);
    ChangeWindowMessageFilter (0x0049, MSGFLT_ADD);

    Sunday, March 28, 2010 1:51 AM
  •  

    So I have tried to make this work on a .NET application in Windows 7 without any luck.

    I based my attempt on what I found here:

     

    • http://social.msdn.microsoft.com/forums/en-US/windowsgeneraldevelopmentissues/thread/8f19b0ba-cb14-4081-8622-c3b3a6481e48/
    • http://it-from-inside.blogspot.com/2010/03/how-to-enable-drag-and-drop-for.html
    • http://social.msdn.microsoft.com/Forums/en-US/windowscompatibility/thread/8d7c530f-0f32-4774-b319-d1724f4d2736
    • http://msdn.microsoft.com/en-us/library/bb625963.aspx

     

    This is what I did:

    1. I added an application manifest in VS.NET 2008 which looks like this:

    <?xml version="1.0" encoding="utf-8"?>
    <asmv1:assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1" xmlns:asmv1="urn:schemas-microsoft-com:asm.v1" xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
      <assemblyIdentity version="1.0.0.0" name="MyApplication.app"/>
      <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
        <security>
          <requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3">
            <requestedExecutionLevel level="requireAdministrator" uiAccess="true" />
          </requestedPrivileges>
        </security>
      </trustInfo>
    </asmv1:assembly>
    
    

    2. In my form I added the following code:

            private const uint WM_DROPFILES = 0x233;
            private const uint WM_COPYDATA = 0x004A;
            private const uint MSGFLT_ADD = 1;
    
            [DllImport("user32.dll", SetLastError = true)]
            public static extern IntPtr ChangeWindowMessageFilter(uint message, uint dwFlag);
    
    

    3. And I call ChangeWindowMessageFilter from the Load event:

                ChangeWindowMessageFilter(WM_DROPFILES, MSGFLT_ADD);
                ChangeWindowMessageFilter(WM_COPYDATA,  MSGFLT_ADD);
                ChangeWindowMessageFilter(0x0049,       MSGFLT_ADD);
    
    

    4. I created a certificate:

     

    makecert -r -pe -n "CN=Test Certificate - For Internal Use Only" -ss PrivateCertStore testcert.cer

     

    5. And use it to sign my application:

    "c:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\SignTool.exe" sign /v /s PrivateCertStore /n "Test Certificate - For Internal Use Only" /t http://timestamp.verisign.com/scripts/timestamp.dll "$(TargetPath)"
    
    

    6. with certmgr.exe I add this certificate to the "Trusted Root Certificate Authorities".

    7. I put the application in a Program Files folder with its DLLs and its manifest.

    8. I also disabled the "Only elevate UIAccess applications that are installed in secure locations"-policy on my computer so It should work outside of the Program Files folder. (I prefer not to do this)

    9. When I start this application I can drag and drop from another application that runs as administrator, but not from the desktop.

     

     

    Can anyone help me to get this to work?

    To Raymond:

    I understand the security issues involved and it is good that this d&d behavior is disabled by default. However there should be a way allow d&d and let the application decide whether it is safe or not to accept the drop.

    For example: the application I am writing uses raw sockets to detect a certain type of devices on the network. These devices are show in a list and I would like to upgrading them using drag and drop. First I will do some basic checks on the dropped files, but also the devices themselves will check if the installer is compatible.

    In this case I really want drag and drop to work and I can handle the security issues myself.

    If you still think this shouldn't be done from a single process, can you work out an example/provide a link to one which shows an application accepting dropped files from the explorer and doing administrator privileged stuff.

    I hope we can find a good solution to this problem which has been bothering people since Vista came out.


    luck favours the prepared
    Saturday, April 3, 2010 8:31 AM