NOTA: Se debe usar GKSU o GKSUDO para ejecutar aplicaciones gráficas desde la terminal en lugar de usar SUDO.

Imagen de RagonichaFulva
0 puntos

Cuando necesitamos ejecutar aplicaciones gráficas con privilegios de superusuario (nautilus y gedit son las más frecuentes)acostumbramos 8al menos yo lo hacía) emplear comandos al estilo:

sudo nautilus

El problema de hacer esto es que si empleamos el comando sudo (de las siglas en inglés de superuser -o substitute user- do) entonces el usuario root se convierte en el propietario de los archivos/carpetas con los que hayamos estado trabajando en modo superusuario. Es por eso que luego a veces nos encontramos que al intentar trabajar con esos archivos/carpetas con nuestro usuario original recibiremos mensajes de que no somos sus propietarios. Es entonces cuando tendremos que modificar los permisos y propiedad de esos archivos/carpetas mediante el comando chown (change owner).

Es por ello que cuando tengamos que ejecutar aplicaciones gráficas con privilegios de superusuario debemos usar los comandos gksu / gksudo (en GNOME y XFCE) o kdesu / kdesudo (en KDE).

Como primera diferencia veremos que en lugar de pedirnos nuestra contraseña en la consola de comandos, nos aparece una ventana gráfica (igual que cuando abrimos Synaptic) donde escribirla.

Lo que ocurre a nivel interno es que el sistema establecerá la siguiente variable:

HOME=~root

y hará una copia del archivo .Xauthority a un directorio temporal, evitando así que root se convierta en el propietario de los documentos del usuario original.

De este modo, el siguiente ejemplos es incorrecto:

$ sudo gedit /etc/X11/xorg.conf

ya que para realizar correctamente esta operación deberíamos escribir:

$ gksu gedit /etc/X11/xorg.conf

o

$ gksudo gedit /etc/X11/xorg.conf

Un saludo!

Fuente:

Por qué se debe usar KDESU ó KDESUDO para ejecutar aplicaciones gráficas desde la terminal, en vez de usar SUDO.

P.D.- Correcciones a lo expuesto más abajo.

Imagen de RagonichaFulva
+1
0
-1

NOTA:

no he podido poner este artículo en la wiki porque no me lo permite. Aduce a problemas de sesion:

Lo sentimos, no pudimos procesar tu edición debido a una pérdida de los datos de sesión. Por favor, prueba de nuevo, y si no funciona, prueba a salir y volver a ingresar.
+1
0
-1

"La perseverancia es un árbol de raíces amargas, pero de frutos muy dulces."

Imagen de Goyo
+1
0
-1

si empleamos el comando sudo (de las siglas en inglés de superuser -o substitute user- do) entonces el usuario root se convierte en el propietario de los archivos/carpetas con los que hayamos estado trabajando en modo superusuario.

Pues a mi no me ocure eso:

user@host:~$ ls -l ~/.bashrc
-rw-r--r-- 1 user user 3103 2010-05-05 18:06 /home/user/.bashrc
user@host:~$ sudo leafpad ~/.bashrc

Hago algunos cambios y guardo el arcihvo. Los permisos no cambian:

user@host:~$ ls -l ~/.bashrc
-rw-r--r-- 1 user user 3103 2010-08-19 12:14 /home/user/.bashrc
De este modo, el siguiente ejemplos es incorrecto:
$ sudo gedit /etc/X11/xorg.conf

Tal vez sea incorrecto pero no porque root se vaya a convertir en propietario del archivo. El propietario de ese archivo *debe* ser root.

+1
0
-1
Imagen de RagonichaFulva
+1
0
-1

Ok Goyo, es cierto que xorg.conf DEBE TENER como propietario a root. Quise poner una orden común en los foros, pero acepto la puntualización. De todos modos no lo corregiré para respetar la coherencia del hilo y que tu aportación resulte pertinente.

En todo caso, lo que os comento no es una ley absoluta. No todas las aplicaciones padecen de esta anomalía.

Para ser honestos, la mayoría del tiempo lo que os menciono no ocurre. Podéis ejecutar aplicaciones de la forma inadecuada (con sudo) y que no hayan efectos adversos.

A pesar de ello, hay veces que pueden haber efectos colaterales de poca importancia como problemas con extensiones de Firefox o tan extremos como que no te sea posible loggearte en ninguna debido a cambios de los permisos en tu .ICEauthority (ver enlace). Esto yo lo he padecido con chromium.

Podéis leer un debate sobre ello en el siguiente enlace:

http://www.mail-archive.com/arch@archlinux.org/msg04963.html

Estos errores ocurren porque a veces cuando sudo lanza una aplicación la lanza con privilegios de root pero emplea el archivo de configuración del usuario.

Por ejemplo, si lanzas Firefox con el comando:

gksudo firefox

se emplea el archivo de configuración de root para firefox.

Pero si lanzas Firefox con el comando:

sudo firefox

lo ejecuta con privilegios de root pero emplea el archivo de configuración del usuario (verás que la página de inicio y el tema son distintos).

Si cambias un par de configuraciones mientras está lanzado como root y verás que si profundizas en el perfil de Firefox algunos archivos ahora pertenecen a root.

Ejecutar aplicaciones gráficas con SUDO también tiene la desventaja de tener siempre que ejecutarlos desde terminal. Si no se emplea el comando gksudo o kdesudo, no serás capaz de usar el comando como un lanzador o un atajo de teclado porque no habrá una ventana de diálogo para que introduzcas la contraseña.

Yo he preferido plantear esto como algo absoluto porque a pesar de que muchas de las veces que empleas sudo para aplicaciones gráficas no ocurre nada, pero hay veces que sí y puede sernos un verdadero engorro o incluso causarnos problemas de cierta gravedad.

Si hacemos excepciones, tendríamos que facilitar a la gente una lista de todas las aplicaciones gráficas que no darán problemas y otra de las aplicaciones que deben emplearse con gksudo o kdesudo.

No hay motivo para hacer una lista que debe ser recopilada y actualizada y que casi nadie referenciará y que es absolutamente innecesaria. Lo mejor es sugerir el uso correcto de cada comando: gksudo y kdesudo para aplicaciones gráficas y sudo para aplicaciones de línea de comandos.

Pero si queremos ahondar más en este tema, gksudo a veces puede soltar un error aunque parezca que funcione, tipo (buscado en internet):

(gedit:####): GnomeUI-WARNING **: While connecting to session manager:
Authentication Rejected, reason : None of the authentication protocols specified are supported and host-based authentication failed.

o bien:

Initializing nautilus-gdu extension
Nautilus-Share-Message: Called "net usershare info" but it failed: 'net usershare' returned error 255: net usershare: cannot open usershare directory /var/lib/samba/usershares. Error No such file or directory
Please ask your system administrator to enable user sharing.

Bien, pues éstos no son verdaderos errores y ya hay un informe del bug del primer caso (ver enlace)que ha sido considerado de baja prioridad (y es del 2005) y otro informe del segundo caso (ver enlace) que ha sido considerado inválido.

Mientras tanto, simplemente ignorad el mensaje y os animo a seguir mi consejo de emplear gksudo y kdesudo para aplicaciones gráficas de forma que no nos arriesguemos a alterar nuestros ~/.ICEauthority u otros archivos de configuración.

Espero que una visión más exhaustiva del tema te sea más satisfactoria Goyo y que os haya sido de utilidad.

Un saludo.

+1
0
-1

"La perseverancia es un árbol de raíces amargas, pero de frutos muy dulces."