Application: gvSIG desktop

Lo del mensaje indicando que no se tiene permiso de escritura, como solución rápida temporal me parece razonable, pero sería cuestión de ir planteando una solución a este tema. Sobretodo porque obligamos al usuario a que lance gvSIG de una forma no estándar, con los problemas adicionales de seguridad que puede provocar. Además en ciertos entornos ni siquiera podrá usar un perfil de administrador.

Una solución sería permitir al usuario que seleccione dónde se guardan los complementos que instala, o hacerlo por defecto en el directorio personal de gvSIG del usuario. Para ello habría que hacer que la librería de instalaciones pudiera soportar varias ubicaciones y añadirle API para poder obtener todos los complementos instalados, quizás filtrados por tipo. Con eso se podría modificar andami, y otros posibles usos (¿simbología?), para que accedieran a los complementos instalador a través del API, en vez de acceder directamente al sistema de archivos.

Hola, estoy de acuerdo en que la solución propuesta no es la mejor a largo plazo, pero respecto a la seguridad no es mejor la solución que planteas, ya que justamente por seguridad los programas se instalan (por defecto) en un directorio en el que el usuario normal no tiene permisos, para que un programa malicioso sin permisos de administrador no pueda modificar otros programas. Si permitimos que los plugins se instalen en un directorio normal, el hipotético programa malicioso podría modificar plugins o instalar nuevos plugins para que hagan cualquier otra cosa. Es cierto que programas como Firefox permiten instalar complementos tanto en el directorio de usuario como en el de sistema, aunque no creo que sea una medida que precisamente refuerce la seguridad...

Si un usuario no puede tener permisos de administrador en una máquina debería instalar gvSIG directamente en su directorio de usuario (asumiendo los riesgos que ello conlleva), ya que de lo contrario no se instalará correctamente.

Para mi la solución correcta sería lanzar el gestor de complementos como una aplicación separada que solicite permisos de administrador (según creo esto es posible en Windows creando un .exe firmado de una forma concreta y en linux hay otras maneras como 'sudo').

En cualquier caso, yendo a un terreno práctico, creo que actualmente la seguridad no puede ser una preocupación mayor en gvSIG ya que hay otras muchas cosas más urgentes y ahora mismo gvSIG no creo que sea un objetivo apetecible para los ciberdelincuentes... No quiero decir debamos ignorar la seguridad, pero sí que la solución temporal que planteo puede ser funcional por mucho tiempo (es sencilla de ejecutar para el usuario, y sólo necesita ejecutar gvSIG como administrador cuando necesite instalar complementos).

... y siguiendo por el terreno práctico y asumiendo que gvSIG no será el paradigma de la seguridad de un día para otro, la verdad es que la solución que planteas tú es mucho más simple de implementar que lanzar el administrador de complementos con permisos elevados, e igual de funcional para el usuario.

En cualquier caso, creo que comenzaría por implementar el mensaje de aviso.

Independientemente de cual sería la solución a medio plazo, que habría que ver pros y contras de las diversas opciones, sí estáis en lo cierto de que actualmente a muchos usuarios les puede dar la sensación de que gvSIG no va en la parte de instalación de complementos.
Y debemos tener en cuenta que sólo un % se inscribe en las listas y pregunta solución o busca en la web la solución.
Una solución "para salir del paso" a corto plazo podría ser buena opción.

Cesar Martinez Izquierdo wrote:

... y siguiendo por el terreno práctico y asumiendo que gvSIG no será el paradigma de la seguridad de un día para otro, la verdad es que la solución que planteas tú es mucho más simple de implementar que lanzar el administrador de complementos con permisos elevados, e igual de funcional para el usuario.

En cualquier caso, creo que comenzaría por implementar el mensaje de aviso.

Fíjate que he hecho más hincapié en la usabilidad que en la seguridad. De todas formas no comparto lo que dices que esa opción es menos segura que hacer que el usuario lance gvSIG con permisos de administrador. Si se instala algo en un directorio del usuario con algún problema de seguridad, siempre será mucho menos pernicioso si sólo tiene permisos de usuario. Si haces que instale con permisos de administrador por el contrario puede instalar lo que quiera, donde quiera, y con permisos totales.

Álvaro Anguix wrote:

Una solución "para salir del paso" a corto plazo podría ser buena opción.

El mensaje al usuario indicándole lo que tiene que hacer creo que es lo más rápido, y al menos le dice al usuario qué tiene que hacer sin que tenga que buscar o ir a las listas.

Aquí hay más información sobre este tema, para el caso de windows:

http://mark.koli.ch/uac-prompt-from-java-createprocess-error740-the-requested-operation-requires-elevation

Parece que, en teoría, creando un ejecutable aparte con la configuración necesaria, podríamos hacer que la instalación de los paquetes se lanzara en un proceso aparte, activando lo de pedir permiso al usuario. De todas formas quizá esto sea muy complejo.

Otra opción podría ir en la línea de lo que propone César y quizás bastante sencilla de hacer. El lanzar el gestor de complementos de forma independiente ya funciona actualmente, de hecho ya incluíamos, al menos en las primeras versiones de gvSIG 2.0, un .exe para ello. Sólo haría falta añadir el "Manifest" correspondiente al generarlo con Launch4J. Por otro lado, el gestor de complementos dentro de gvSIG podría hacer la validación de permisos y no estar activo sino puede escribir, indicando al usuario que use el otro ejecutable.

Esto mismo en el caso de linux se podría hacer también con un .sh que arranque sólo el instalador de complementos, usando el gksu, gksudo, kdesudo o similares.

Hola Cèsar, muy interesante el link que envías. Las conclusion más importante es que la elevación de privilegios se ha de hacer forzosamente desde código nativo (usando ShellExecute). Es decir, añadir el Manifest al .exe y lanzarlo directamente desde Java falla con un error "CreateProcess error=740, La operación solicitada requiere elevación" (aunque sí funcione haciendo doble click desde el Explorador de ficheros).

Por otra parte, he visto que si un ejecutable se renombra a setup.exe automáticamente abre el diálogo UAC sin necesidad siquiera de crear un manifest. Eso sí, igual que en el caso anterior, sólo funciona al lanzar desde código nativo o al hacer doble click.

Juntando todo esto, he hecho una prueba muy sencilla con la librerías JNA/JNA Platform que permiten ejecutar código nativo sin crear JNIs. He renombrado el instalador de gvSIG a "setup.exe" y lo he lanzado desde Java con el siguiente código:

package test;
import com.sun.jna.platform.win32.Shell32;
public class TestShell32 {
public static void main(String[] args) {
Shell32 shell = Shell32.INSTANCE;
shell.ShellExecute(null, "open", "D:\\Users\\c_martinez\\Downloads\\setup.exe", "", "D:\\Users\\c_martinez\\Downloads", 5);
}
}

Y... ¡bingo¡ Se abre el UAC automáticamente. Esto lo podríamos aplicar bastante fácilmente si incluimos el gestor de complementos como ejecutable.

Todo esto me interesa también por otro lado, ya que estoy preparando una extensión que añade una página de preferencias para configurar la memoria de gvSIG, y en Windows hay el mismo problema (el fichero de configuración sólo puede escribirse por el administrador).

Bueno, casi cerrando ya el círculo, veo que el gestor de complementos ya se incluye como aplicación separada, y que además, por contener la palabra "install" en el nombre del .exe también activa automáticamente el diálogo UAC, con lo cual es trivial lanzarlo con permisos elevados:

shell.ShellExecute(null, "open", "C:\\Program Files (x86)\\gvSIG desktop 2.1.0_build2245\\gvsig-package-installer.exe", "", "C:\\Program Files (x86)\\gvSIG desktop 2.1.0_build2245\\", 5);

Sólo necesitaríamos añadir la dependencia a las librerías JNA y JNA platform.

Hola Cesar M.
El instalador de complementos ya tenia cierto soporte para gestionar
multiples carpetas en las que buscar los complementos.
Se usaba principalmente para otras cosas que no eran plugins, pero
pensando que podria ser facil extenderlo a los plugins he realizado
las modificaciones necesarias.
He tenido que tocar mas cosas de las que creia, mas que nada por
que aun se hacia uso en bastantes sitios de metodos deprecateds, pero
ya funciona.
De momento lo he dejado que intente instalar en la primera carpeta
de las indicadas para el tipo de addon en la que se tenga permiso
para escribir, y he dejado que para el tipo "plugin" primero lo
intente en la carpeta de la instalacion y luego en una dentro de
"HOME/gvSIG". Lo he provado en linux y parece que funciona.

Respecto a lanzar el administrador de complementos desde gvSIG como
una aplicacion independiente, asi sin mas, no creo que sea buena idea.
Hay complementos que se registran en plugins de gvSIG, y si se arranca
gvSIG sin cargar esos plugins, que es el caso de cuando arrancamos el
gestor de complementos como exe independiente, no estan registrados
esos tipos de complementos, con lo que no se pueden instalar (por ejemplo
juegos de simbolos o BBDD de CRSs de EPSG).

De momento podria se un amago de solucion parcial, ya que no parece lo
mas adecuado dejar binarios en "HOME/gvSIG", Aunque por otro lado permitiria
a usuarios sin privilegios de administracion poder instalar complementos
en su gvSIG (instalaciones corporativas). Hay que tener en cuenta que
seria muy facil deshabilitar esta opcion desde un plugin de personalizacion
en caso de que se quisiese evitar.

Ademas se me ha planteado un problema... o algo asi.
Tengo el plugin X-1.0.0 instalado en la instalacion de gvSIG, y trato de
actualizarlo a la X-1.0.1. Como no tengo permiso para instalarlo la
actulizacion entra en "HOME/gvSIG" quedando en la carpeta de la instalacion
la original. Creo/espero que, por mera casualidad, arrancara con el que
hay en "HOME/gvSIG" ignorando el otro, pero no lo he probado aun.

Hola Joaquín, he probado el build 2246 pero el problema persiste, entiendo que no se ha incluido el cambio en este build.

El problema que se te ha planteado, ¿podría surgir también si se instalan 2 versiones de un plugin como administrador? Yo creo que lo ideal sería que cogiese el de versión más alta e ignorase el resto, aunque tampoco creo que sea necesario cubrir toda la casuística para la 2.1.

El problema del registro de los plugins al lanzar el administrador de complementos como aplicación independiente no lo conozco, pero quizá en futuras versiones podemos repensar el proceso de registro para evitar estos problemas.