¿Puede haber algún problema al usar gedit para editar archivos del sistema con ‘sudo -H gedit’?

Solución:

Siempre que lo ejecutes correctamente, es una cuestión de tu preferencia.

Aparte de las diferencias en características, el editor de texto que utilice es de hecho su preferencia. Este es true incluso cuando su editor de texto sea un programa gráfico como Gedit. Esto no quiere decir que no haya una buena razón nano y vim se recomiendan a menudo. Editores de texto basados ​​en terminales como vim (o al menos un vi comando) y nano están disponibles incluso cuando no hay GUI e incluso en la mayoría de los sistemas mínimos y rotos; tienen algo de tradición detrás de ellos (si eres partidario de ese tipo de cosas); se pueden ejecutar en el mismo terminal en el que se realizan otras tareas; se integran automáticamente en los flujos de trabajo de los usuarios de multiplexores de terminales; y es más probable que estén disponibles que cualquier especial editor de texto gráfico, incluso Gedit, incluso en Ubuntu (que tiene varios sabores).

Eso no es todo. Si va a editar archivos del sistema, un enfoque es ejecutar su editor como root. Este es no el único enfoque, y hay algunos argumentos en contra (ver más abajo), pero es uno común. Si adoptas ese enfoque y use un programa gráfico como editor, entonces debe tener cuidado de ejecutarlo de tal manera que $HOME es el directorio de inicio de root en lugar del suyo, y esto agrega otra capa de molestia y complejidad. Pero ya lo estás haciendo; estas corriendo sudo -H gedit, que es una de las formas razonables. Aún así, esa complejidad es otra razón por la que la gente tiende a sugerir editores no gráficos.

Los programas gráficos suelen ser más complicados que los programas no gráficos. Tener más cosas ejecutándose como root es generalmente malo, ya que hay más formas en las que las cosas podrían salir mal, incluso debido a posibles errores, incluso por accidente. (Editores de texto no gráficos como vim Sin embargo, también son bastante sofisticados y, a menudo, están configurados para ejecutar numerosos programas externos para realizar diversas tareas).

Además de ejecutar el editor como root, otro enfoque general es editar un archivo que el editor puede modificar incluso cuando se ejecuta como su usuario (no root), de modo que los cambios en el archivo se propagan al archivo de propiedad raíz que desea cambiar. Eso suena abstracto porque los detalles varían considerablemente. A continuación se presentan dos enfoques concretos importantes.

sudoedit

Una forma bastante antigua de hacer esto es sudoedit (documentado en la misma página del manual que sudo). Por defecto, sudoedit utiliza el editor de texto predeterminado, que normalmente no es, ni debería ser, un programa gráfico. Pero puede decirle que use cualquier editor a través del SUDO_EDITOR, VISUAL, o EDITOR variables de entorno, que consulta en ese orden. Así puedes ejecutar:

VISUAL=gedit sudoedit filename

Reemplazar filename con una ruta relativa o absoluta a su archivo.

Esto crea una copia temporal del archivo que desea editar. La copia es de su propiedad, no de root (o de quien sea el propietario original). Abre el editor de texto y puede editar la copia temporal. Cuando usted cerrar el editor de texto, sudoedit comprueba si realmente hizo cambios. Si lo hizo, copia la copia temporal modificada espalda al original.

Tiempo sudoedit funciona con editores gráficos, también es útil para editores basados ​​en terminales. En ambos casos, el editor de texto se ejecuta como tú, por lo que tiene tu configuración y otras acciones que realizas en él. otro que las modificaciones realizadas en ese archivo las realiza usted, lo que permite un poquito de protección contra algunos tipos de errores.

Puede configurar una de esas variables de entorno de forma persistente si lo desea. SUDO_EDITOR es quizás el mejor ya que se usa para menos otras cosas. Sin embargo, si lo configura en gedit, ten en cuenta que comandos como sudoedit filename no funcionará cuando no haya una GUI disponible, como suele ocurrir (aunque no siempre) en una consola virtual o mediante SSH.

El backend de administración de GVFS

Otra forma más nueva de hacer esto es abrir el archivo a través de su GVFS admin:// path en lugar de su ruta tradicional de estilo Unix. Gracias a pomsky por enseñarme sobre esto. Del mismo modo que existen rutas GVFS para editar archivos que, en otros aspectos, no se encuentran en un lugar conveniente para editarlos, por ejemplo, porque están en una máquina remota a la que está conectado a través de SSH, GVFS admite admin:// rutas para editar archivos que no son de su propiedad.

Esto es conceptualmente similar a sudoedit en el sentido de que ejecuta su editor como usted mismo y el archivo que ve el editor es algo que puede editar. Intentar abrir el archivo requiere que se autentique; esta no es una forma mágica de eludir las restricciones de seguridad habituales.

gedit admin:///path/to/filename

Allí, /path/to/filename debe ser una ruta absoluta al archivo, comenzando con /. Entonces hay tres / personajes después admin:.

Codificaciones y otras cosas teóricamente afectado por la configuración del editor

La codificación de un archivo no se ve realmente afectada por si el editor que utiliza es gráfico o no. Algunos editores, como vim, incluso puede operar gráficamente (el gvim comando) o no gráficamente (el vim mando). La respuesta simple a su pregunta sobre codificaciones es que no tengo que preocuparme por eso. Eso está lo suficientemente cerca de la verdad que realmente no tiene que leer el resto de esta respuesta.

En las versiones actuales (y pasadas) de Ubuntu, comandos como sudo nano y sudo vim ejecutar esos editores como root pero tener $HOME todavía configurado en tu directorio de inicio. Esto significa que los editores utilizarán, de forma predeterminada tu configuración en lugar de la configuración de root. Si hay algo en la configuración de esos editores (o en un programa que ejecutan para hacer parte de su trabajo, como git) sobre codificaciones o finales de línea, se seguirá. Con sudo -H editor, eso no sucederá.

Algunas personas usan desnudo sudo (es decir, sin -i o -H) a los editores porque quieren eso. Pero realmente, deberías pensarlo dos veces. No solo puede lograr ese objetivo de manera más limpia con un método como sudoedit, hay otras desventajas de los comandos como sudo nano y sudo vim:

• Si la configuración de su editor hace que se ejecute algo, se ejecutará como root. Para editores sofisticados como vim, esto puede hacer que una gran cantidad de código no trivial se ejecute como root. Como se mencionó anteriormente, tener menos código ejecutado como root es generalmente bueno y este es uno de los argumentos en contra de ejecutar editores gráficos como root.

  Si tu vim La configuración tiene numerosos complementos, por ejemplo, para realizar static análisis en el código fuente a medida que lo escribe, y root no lo hace, menos cosas se ejecutan como root con sudo -H vim filename que sudo vim filename. (Incluso menos se ejecuta como root con VISUAL=vim sudoedit filename, ¡pero sus complementos aún funcionan!) Esto es independiente de si su editor es gráfico o no.

• Si la configuración de su editor está rota y le impide editar archivos fácilmente, arreglarlo puede ser aún más complicado, ya que también se aplica a la raíz. Esto es simplemente una molestia, no un problema difícil de resolver.

• Comandos como sudo vim tengo un poquito del mismo problema que el comando (¡desaconsejado!) sudo gedit. Si ejecuta un editor como vim como root pero sin resetear $HOME (como sudo -H y sudo -i haría), y crea archivos de configuración para sí mismo, esos archivos de configuración residirán en su directorio de inicio pero serán propiedad de root, y su configuración puede estar algo rota cuando luego ejecute el editor como usted mismo.

  Bueno, esto seguro suena mucho a ¡ese problema! La razón por la que es menos importante que con las aplicaciones gráficas es que el editor por lo general todavía se inicia, los mensajes de error suelen ser más fáciles de entender, por lo general puede averiguar qué archivos específicos se ven afectados con mucha más facilidad y la rotura generalmente se limita a ese programa. (Los programas gráficos usan archivos de configuración en más lugares). Además, a diferencia de los editores gráficos, los usuarios que solo por casualidad Si usa un editor de texto y no cambia deliberadamente su configuración, es poco probable que experimente este problema.

Nuevamente, puede usar la configuración del editor de su propia cuenta de usuario mientras evita problemas de permisos usando sudoedit o, desde el escritorio, iniciando el editor normalmente pero accediendo al archivo a través de un admin:// sendero.

Finalmente, tenga en cuenta que el comportamiento mencionado anteriormente de sudo cuando -H o -i se pasa está planeado cambiar en una versión futura de Ubuntu (como ya lo ha hecho, hace años, en la mayoría de los sistemas operativos similares a Unix que usan sudo). El comportamiento ya ha cambiado en Ubuntu 19.10, que es la versión de desarrollo al momento de escribir este artículo.

Para responder a su pregunta: en general, el uso de un editor de GUI no será un problema aparte de gedit siendo muy lento para archivos grandes.

Pero para los programas de GUI usaría pkexec o gksu en lugar de sudo. Es posible que deba configurar pkexec antes de que funcione.

pkexec gedit

o para versiones anteriores de Ubuntu (por ejemplo, 16.04) puede usar:

gksu gedit

(Aunque puede probar mejores editores de GUI, p. Ej. geany ;-))

Si piensas que te ha resultado provechoso este artículo, te agradeceríamos que lo compartas con el resto desarrolladores así contrubuyes a extender nuestro contenido.

---

---

Utiliza Nuestro Buscador