0

I have two application which is a main and a sub. both can also be opened separately and the main can also open the sub.Since the main application is in the administrative mode, the sub-application when opened from the main application is also opening in the same mode. Is there any possible way where can I open the sub-application in a normal but I need to have the base application running in the admin mode. The problem is I need to drag and drop files in the sub-application which cant be done when the application is in administrator mode.

Shyahshi
  • 1
  • 2
  • Raymond Chen wrote a good post on [How can I launch an unelevated process from my elevated process and vice versa?](https://blogs.msdn.microsoft.com/oldnewthing/20131118-00/?p=2643) – Damien_The_Unbeliever Apr 24 '18 at 08:24
  • I would maybe look at spawning a separate process for the sub-application using a different app domain. I can elaborate as an answer if you want? – DotNetHitMan Apr 24 '18 at 08:25
  • 2
    This is a clear case of the [XY problem](https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem). You should be looking at the actual issue, which is not being able to drag and drop files while running with elevated privileges. – Flater Apr 24 '18 at 08:25
  • @DotNetHitMan - not sure what you're going to offer, but since App Domains are *contained* within processes, your comment doesn't make a great deal of sense. – Damien_The_Unbeliever Apr 24 '18 at 08:28
  • @Flater - It's a well known issue that drag and drop has issues with UIPI, because it's done using window messages and the whole point of UIPI is to prevent low-privilege applications sending messages to high-privilege applications. – Damien_The_Unbeliever Apr 24 '18 at 08:30
  • @Damien_The_Unbeliever hi mate, the OP mentions that he wants to run the sub program in no admin mode when launched from the main app which is run in admin mode. I was thinking that you could create a new app domain and set the user principle of the new app domain to be a none admin user. Then spawn a new process within that app domain to run the sub application. (not tested or ratified hence adding as a comment not an answer). – DotNetHitMan Apr 24 '18 at 08:32
  • I concur that this does sound like a XY problem. *Why* can you not use Drag & Drop on a application with Elevated Privileges? Could you use any other from of Interprocess Communciation to get hte data across? https://msdn.microsoft.com/en-us/library/windows/desktop/aa365574.aspx – Christopher Apr 24 '18 at 08:33
  • @Christopher - I think you're thinking of drag and drop within the application or between two applications that the OP is authoring. You can't change what mechanism Windows Explorer uses for file drag & drop. – Damien_The_Unbeliever Apr 24 '18 at 08:37
  • @Damien_The_Unbeliever: D&D is just one of the ways to do IPC. It is a approach that effectively will use the Clipboard or something like. Especially the Pipe and Network based IPC's can cross any borders. – Christopher Apr 24 '18 at 08:39
  • Possible duplicate of [How do you de-elevate privileges for a child process](https://stackoverflow.com/questions/1173630/how-do-you-de-elevate-privileges-for-a-child-process) – NtFreX Apr 24 '18 at 08:40
  • @Christopher - but again, you cannot change **Explorers** behaviour. Application launches. User opens an explorer window and finds one or more files. User drags those files onto your application. If the application is elevated, this fails (assuming Explorer itself hasn't been elevated). Yes, you can use other IPC mechanisms *when you can control both ends of the communication* but it's irrelevant when the other end is written by someone else who isn't going to collaborate in your plan to change the IPC mechanism. – Damien_The_Unbeliever Apr 24 '18 at 08:44

1 Answers1

0

Getting rid of Adminsitrative Privileges is surprisingly hard. It is nigh impossible to get rid of them, like starting a non-Elevated Process from a elevated one. It is a a vexing property of Windows.

There are ways but they usually involve unmanaged code (Windows API) and are not that stable.

It is possibly if you have the Application user/System Adminsitrator Specify a specific Windows User that he he maintains explicitly as one without Administrative Privileges. The way most non-elevated Services are started is by a explicit Windows User that is set in the Service Manager.

Most programmers eventualy settle to dodge this Problem entirely via an approach like this:

  • Have both Process A and B designed to always start non-Elevated (no Manifest or anything demand Elevation)
  • Modify Process A to detect that it is non-Elevated right now
  • Let Process A try to start a Elevated copy of itself via Runas with proper Options.
  • If the user is always Elevated (because the UAC is turned off or soemthing like that), it is out of your hands.
  • As I learned the hard way, there is also a chance that elevation might fail due to faulty Windows configuration. Again, this is out of your hands.

Of course there is the big question of why this is a Problem to begin with and if that is perhaps a XY Problem. Drag & Drop might have those limits. But do you have to use D&D for this? There are many ways to go about Interprocess Communicaiton. Most of them do not suffer such Limitations. D&D is just one of them.

Christopher
  • 9,634
  • 2
  • 17
  • 31