¿Cómo funciona el montaje en la GUI "debajo del capó"?

12

ACTUALIZAR

Corríjame si me equivoco : para trabajar en mi computadora, con una distribución GNU / Linux llamada Debian, conozco dos formas de ingresar un comando, iniciar una aplicación, abrir un archivo, etc.

  • una interfaz de línea de comando donde ingreso texto
  • una interfaz gráfica de usuario [también conocida como GUI ]: una interfaz que proporciona "ventanas", símbolos, etc.

Algo se llama "Administrador de ventanas". Como uso GNU / Linux, trabajo en el sistema X-Window [que yo sepa].

ingrese la descripción de la imagen aquí


Publicación original


Situación : deshabilité el montaje automático /etc/fstabpara memorias USB [p /dev/sdb1. Ej .]. El montaje requiere ser root, o al menos una sudoentrada en la línea de comando, pero no en un administrador de ventanas (!) . No quiero decir automount, me refiero a "hacer clic en el símbolo" en un administrador de ventanas abre el dispositivo en la GUI sin ninguna pregunta, donde en la CLI uno debe ser root.

Pregunta : ¿Cómo funciona el montaje en una GUI "debajo del capó"? ¿Existe un configarchivo para los gestores de ventanas en general o hay que configurarlo individualmente?

Entiendo y uso el mountcomando, creo entender cómo leer y configurar /etc/fstaby saber dónde mirar qué significan las entradas allí y en el /etc/mtabmedio.

erch
fuente
1
Además, los administradores de ventanas AFAIK no son responsables de esto; lo importante es el (parte del) entorno de escritorio que se ejecuta debajo. Por ejemplo, uso Awesome GNOME (GNOME usando Awesome en lugar de GNOME Shell) y discos automount. pero no lo harían si simplemente usara Awesome. honestamente, no entiendo tu recompensa, la respuesta de @ slm parece bastante clara
Strugee
2
En los primeros días, era el automontador que hacía estos trucos en segundo plano (con casi el mismo comando de montaje que usarías en el root-cli). Ahora hay subprocesos propios que se integran con la GUI que hacen el trabajo. Ver la respuesta de slm.
Nils
55
"Me resulta difícil creer que todos y cada uno de [los distintos administradores de ventanas] tengan que buscar su propia forma de resolver esto". -> Nunca es el administrador de ventanas (WM) el que hace esto. Es el entorno de escritorio (DE). En cuanto a que todos tienen que hacerlo ellos mismos, bueno, también hacen muchas otras cosas por sí mismos. Por elección . Pero no tienen que hacerlo. GNOME, por ejemplo, tiene una licencia GPL, por lo que cualquier otra GPL'd DE podría usar partes de GNOME, si así lo desean.
Ricitos de oro
2
@goldilocks que, por ejemplo, Cinnamon y MATE hicieron.
Strugee
2
@strugee: GNOME tiene una estrecha relación histórica con GTK (que originalmente era para GIMP), y las bibliotecas de soporte de nivel inferior ( glib ) que GNU también mantiene y creo que proliferaron de GNOME y GTK. Supongo que casi todo el mundo hace de glib, proporciona muchas cosas fundamentales para una GUI multitarea, dirigida por eventos "bajo el capó" (solo: no las partes gráficas reales). Creo que GNOME es fundamentalmente glib + gtk + un administrador de windom + algunas aplicaciones.
Ricitos de oro

Respuestas:

5

Esta es mi comprensión de la situación, pero no soy un experto, por lo que es menos técnico que las otras respuestas. Esto es lo que entiendo después de usar estos sistemas durante muchos años, no los he estudiado en detalle.

Aquí hay tres jugadores principales y entre ellos gestionan las monturas:

  • FUSIBLE: Esto está en el centro de todo, como se describe en su página de wikipedia :

    El sistema de archivos en el espacio de usuario (FUSE) es un mecanismo de sistema operativo para sistemas operativos de computadora tipo Unix que permite a los usuarios no privilegiados crear sus propios sistemas de archivos sin editar el código del núcleo. Esto se logra ejecutando el código del sistema de archivos en el espacio del usuario, mientras que el módulo FUSE proporciona solo un "puente" a las interfaces reales del núcleo.

    Entonces, básicamente, esto es lo que permite a los usuarios sin privilegios montar sistemas de archivos.

  • gvfs: En la familia Gnome de entornos de escritorio (que incluye Gnome, Mate, Cinnamon), este es (entre otras cosas) un demonio que montará automáticamente las unidades recién conectadas. Lo hace a través de FUSE. Creo (pero puede estar equivocado) que el equivalente para la familia KDE se llama KIO

    Los principales procesos de gvfsson (tomados de man gvfs):

    • gvfsd - el demonio gvfs principal
    • gvfs-fuse-daemon - monta gvfs como un sistema de archivos fusible
    • gvfsd-metadata - escribe metadatos gvfs
  • udev: Este es un sistema que detecta nuevos dispositivos y le permite ejecutar scripts / comandos cuando están conectados. Por ejemplo, es udevque detecta una nueva pantalla y puede reflejar su escritorio en ella:

    udev es un administrador de dispositivos para el kernel de Linux. Principalmente, administra nodos de dispositivos en / dev. Es el sucesor de devfs y hotplug, lo que significa que maneja el directorio / dev y todas las acciones de espacio de usuario al agregar / eliminar dispositivos, incluida la carga de firmware.

    Específicamente, gvfsparece funcionar a través de gvfs-udisks2-volume-monitorun monitor de volumen basado en udiscos. udiskssin embargo, se basa en udev(ver man 7 udisks).

Entonces, básicamente (lea "simplificación horrible") lo que sucede es que cuando conecta su unidad, la udevdetecta y alerta al gvfsdemonio que luego lo montará como un dispositivo FUSE.

FUSE y udevserá el mismo para todos los entornos de escritorio, lo que cambia es el demonio DE que monitorea udevy monta la unidad como un sistema de archivos FUSE.

terdon
fuente
1
Ponga D-bus llenando los espacios entre udev, gvfs y todo lo demás.
Braiam
Es posible que desee actualizar la información sobre gvfs. Se están mudando a GIO.
Braiam
8

Depende de su entorno de ventanas (GNOME / KDE / etc.), Pero en GNOME, por ejemplo, verá los demonios ejecutándose llamados, gvfs-*-volume-monitor. Estos demonios son responsables de montar dispositivos cuando se ejecuta el entorno de escritorio, no tienen nada que ver /etc/fstaby funcionan de manera completamente independiente.

En cuanto a un archivo de configuración, hay algunos archivos que están relacionados con esto que viven en el directorio personal del usuario que ejecuta el DE, $HOME/.local/share/gvfs-metadata.

Este U&L Q&A titulado: ¿Qué es gvfs y por qué debería quererlo en mi sistema? , intenta explicar qué es GVFS. Hace un buen trabajo al explicarlo. Pero creo que lo que realmente está preguntando se aborda más en este Q&A de U&L titulado: Montaje de discos USB automáticamente (Cómo funciona) .

slm
fuente
La respuesta parece estar en HAL... Encontré algunas soluciones para thunar[que uso] etc. El artículo apuntó en una dirección. ¡Gracias por eso! - pero todavía estoy buscando un denominador común ...
erch
IIRC el DE no necesita root porque usa FUSE (Sistema de archivos en el espacio del usuario).
Strugee
@strugee adivinando que DE significa entorno de escritorio, debería buscar en FUSE. ¿Tienes una pista, dónde?
erch
@chirp busque FUSE en Wikipedia: en.wikipedia.org/wiki/FUSE is it, IIRC. y slm ya ha respondido. la respuesta es que el entorno de escritorio, no el administrador de ventanas, realiza el montaje automático.
Strugee
2
@chirp - Ver aquí: bbs.archlinux.org/viewtopic.php?id=95509 . HAL ha quedado en desuso, en.wikipedia.org/wiki/HAL_(software) . UDEV es el reemplazo en el futuro: en.wikipedia.org/wiki/Udev
slm
8

La respuesta simple es que hacen trampa. Ellos no usan el fstab. Por lo general, usan un udevgancho para capturar eventos de inserción, montan el disco manualmente root, lo que se puede pasar dbuspara notificar a su administrador de archivos que tiene un disco nuevo o pueden usar suidutilidades en lugar de dbusdesmontarlo. Desafortunadamente, no hay opciones de configuración estándar para esto, y dado que el movimiento del escritorio cree en ocultar la complejidad, no documentan esto en la documentación del usuario, solo en la documentación del desarrollador, y asumen un solo sistema de usuario, por lo que las unidades USB solo funcionan para primer usuario en iniciar sesión en un servidor X.

hildred
fuente
¡SI! Esto es más de lo que estoy buscando. Como nuevo, me gustaría preguntar dónde comenzar a buscar, erm: "¿Dónde empiezo?" Para rastrear este comportamiento [cualquier pista me ayudaría a desviarme; un punto de partida más o menos sería de gran ayuda]
erch
2
@chirp para comenzar a explorar mira udev (7) y /etc/udev/rules.d/*
hildred
5

PolicyKit (o Polkit) es un kit de herramientas de nivel de aplicación para definir y manejar la política que permite que los procesos no privilegiados hablen a procesos privilegiados .

Es un marco para centralizar el proceso de toma de decisiones con respecto a la concesión de acceso a operaciones privilegiadas (como llamar al método Mount ()) para aplicaciones no privilegiadas (de escritorio).

Se utiliza un agente de autenticación para hacer que el usuario de una sesión pruebe que el usuario de la sesión realmente es el usuario (autenticándose como usuario) o un usuario administrativo (autenticándose como administrador).

GVFS es un sistema de archivos virtual que permite el montaje de sistemas de archivos locales y remotos como usuario junto con el soporte de basura. También hay soporte FUSE que permite que las aplicaciones que no usan GIO accedan a los sistemas de archivos GVFS, pero la mayoría de los DE también se autentican a través de Policykit para otras cosas, como hibernar y apagar la computadora, y para NetworkManager, por lo que no necesitan use FUSIBLE.

Está formado por dos partes:

  1. Una biblioteca compartida cargada por aplicaciones que admiten GIO;
  2. GVFS en sí, que contiene una colección de demonios que se comunican entre sí y con el módulo GIO a través de D-Bus.

El paquete gvfs necesita ser instalado, junto con polkit-gnome para las reglas de polkit. Asegúrese de que haya instalado un agente de autenticación gráfica y que se inicie automáticamente.

Los archivos de configuración para administrar privilegios deben ser diferentes para cada distribución. Arch Wiki te dice que crees un archivo debajo /usr/share/polkit-1/rules.d/. En Debian, están ubicados en /etc/polkit-1/.

Fuentes: Policykit en Debian || Polkit en Arch Wiki || GVFS en Arch Wiki || ¡GVFS en GNOME Wiki!

Teresa e Junior
fuente
¿Estás seguro de que GIO significa GObject Introspection? Hubiera pensado que se llamaría GOI si es así. La gente Gnome parece llamarlo GI . No he encontrado otra explicación del nombre de GIO, pero no parece ser lo mismo que GI.
terdon
@terdon Esa fue en realidad una edición de strugee (revisión 10 en unix.stackexchange.com/posts/101951/revisions ). Quitándolo ...
Teresa e Junior
4

Un elemento común que está buscando es FUSE , el gvfs de GNOME, por ejemplo, lo usa bajo el capó. 1 Esta es la interfaz con el kernel, y creo que es común a todos los sistemas de montaje sin privilegios (automáticos) en Linux [pero vea los comentarios]. Los DE individuales no crearían su propia versión de esto, ya que eso requeriría parches del kernel.

De hecho, el enlace de la página de inicio está desactualizado, porque como se señaló aquí , FUSE se convirtió en parte del núcleo oficial hace unos años, pero describe los orígenes y propósitos del proyecto (no es solo para un montaje sin privilegios).

La razón por la que varios sistemas pueden diferir en estilo más allá de esto es la misma razón por la que tiene varios entornos de escritorio: representan diferentes visiones de cómo / qué debería ser la GUI. Se ocupan de la forma y la función de la interfaz de usuario, pero FUSE hace el montaje real y el nivel de kernel. Nota que se fusionan en realidad no hace parte de la "auto", se trata más de la parte "no privilegiados", pero la pieza de automóvil es bastante simple: todo lo que tiene que hacer es encuesta, por ejemplo, /dev. He escrito una aplicación de montaje que funciona de esta manera; solo observa la aparición de nuevos nodos. 2 Esa parte es tal vez un centenar de líneas de C ++. Easy-peasy: no hay necesidad real de una API común en ese nivel.

1 O puede, si está haciendo una montura realmente sin privilegios. La respuesta de Teresa puede cubrir enfoques más nuevos para permitir el acceso a monturas normales.

2 Como observa Hildred, las devoluciones de llamadas udev serían un método mejor y menos pirateado.

encerrada dorada
fuente
Supongo que querías decir "página de inicio" y borraré este comentario después de que desapareció el error tipográfico;) ¡Gran respuesta, como siempre, por cierto!
erch
1
Como nuestras respuestas parecen contradecirse, hice algunas pruebas. Al menos en Debian, sin un agente Polkit activo, el usuario no puede montar. Además, el módulo fuse.ko no se carga incluso después de montarlo. (Estoy usando Thunar en Wheezy)
Teresa e Junior
3
@TeresaeJunior: Punto (he agregado una referencia aquí), aunque no creo que haya una contradicción ya que la ruta polkit es un poco un truco de espacio de usuario: el montaje sigue siendo un montaje privilegiado. La página de wikipedia de GVFS señala que "GVFS puede usar FUSE", así que haré que "may" en lugar de "does".
Ricitos de oro
1
Desde el Wiki de GNOME: "También hay soporte para fusibles que permite que las aplicaciones que no usan gio accedan a los sistemas de archivos gvfs".
Teresa e Junior
1
@TeresaeJunior: Sí, por lo que son algo concurrentes, FUSE es una alternativa. Por supuesto, GNOME no es el único DE, pero estoy seguro de que la mayoría de los demás usan glib (que incluye gio) de varias maneras. TBH Nunca me ha gustado el montaje automático, así que no tengo ninguna anécdota al respecto. De todos modos, FUSE es una posibilidad.
Ricitos de oro