2010-09-22 15 views
6

Tengo una aplicación C# que se ejecuta y muestra un icono de bandeja. Tengo un instalador para mi aplicación de bandeja que inicia la aplicación después de la instalación. El instalador requiere permisos de administrador, mientras que el icono de la bandeja debe ejecutarse con permisos normales. Mi instalador actualmente lo rompe: cuando se lanza la aplicación de la bandeja instalada, hereda los permisos de administrador del proceso del instalador.Cómo iniciar un programa con permisos de usuario en lugar de permisos activos

Como parte de mi instalador, estoy lanzando una aplicación C# para realizar algunos trabajos personalizados. Esta pequeña aplicación actualmente pone en marcha la aplicación de la bandeja llamando:

Process.Start(@"path/to/my/tray/app.exe"); 

¿Hay alguna forma para invocar la aplicación bandeja con los permisos del usuario actual en lugar de los permisos elevados dadas al instalador?

He oído que la forma recomendada de hacerlo es tener un contenedor EXE alrededor del instalador que inicia el instalador y luego inicia el programa instalado. Me gustaría evitar esto si es posible.

Estoy usando WiX para construir un instalador MSI, así que también aceptaría soluciones que funcionan directamente desde WiX/MSI.

Respuesta

0

Muy buena pregunta. Las respuestas que encontré que aparentemente funcionan son un poco desordenadas; el más elegante en general es el contenedor EXE.

Echa un vistazo a este artículo: http://www.codeproject.com/KB/vista-security/RunNonElevated.aspx. Describe un método mediante el cual puede obtener un enlace nativo a una de las ventanas del shell, que se ejecutan no elevadas, y le pide al shell que inicie su código por usted. Los ganchos nativos en C# requieren permisos CAS muy altos; para obtener estos permisos, su instalador debe estar fuertemente identificado y firmado, y el código debe exigir o afirmar SecurityPermission con SecurityPermissionFlag.UnmanagedCode.

La clase ProcessStartInfo de .NET Framework también contiene una propiedad UseShellExecute Boolean que, cuando se establece, le dice a Process.Start() que proporcione esta llamada al shell en lugar de iniciar el proceso directamente desde el dominio de aplicación actual. No sé si esto hará lo que necesita, pero definitivamente es mucho más fácil de probar; simplemente usa la sobrecarga ProcessStartInfo de Process.Start(), con un ProcessStartInfo declarado que tiene el indicador establecido.

Recuerde que no puede decirle al shell que inicie un EXE como un usuario que no sea el usuario actualmente conectado (UserName y Password no se deben establecer en ProcessStartInfo). También debe especificar la ruta al EXE utilizando la propiedad WorkingDirectory.

+0

UseShellExecute aparentemente está predeterminado en true, por lo que parece que esto no ayudará aunque todavía no lo haya intentado. Gracias por su respuesta, pero sospecho que el administrador de paquetes será la única solución "ordenada". – mchr

+0

Ahora lo he probado y no funciona. También probé un dll de C++ llamando a http://msdn.microsoft.com/en-us/library/aa446583%28v=vs.85%29.aspx y lanzando con el nuevo token de seguridad. Sin embargo, esto no puede alterar al usuario que posee el proceso lanzado, solo los permisos que tiene el proceso lanzado. – mchr

3

Hay dos enfoques. Lo más simple es usar un ejecutable shell que primero lance la tarea de administración elevada (muchas formas de hacerlo, prefiero un manifiesto) y luego la otra tarea no elevada. Si se niega a hacerlo por cualquier motivo, eche un vistazo a la publicación de blog y al proyecto CodePlex al que me enlace desde mi blog en este: http://www.gregcons.com/KateBlog/NonElevatedFromElevatedManagedThisTime.aspx

Cuestiones relacionadas