¿Por qué Mount requiere privilegios de root?

¿Por qué Linux requiere que un usuario sea root / use sudo / específicamente autorizado por montaje para montar algo? Parece que la decisión de permitir a un usuario montar algo debe basarse en sus derechos de acceso al volumen de origen / recurso compartido de red y al punto de montaje. Un par de usos para el montaje no root es montar imágenes del sistema de archivos en una dirección propiedad del usuario y montar un recurso compartido de red en un directorio propiedad del usuario. Parece que si el usuario tiene control sobre ambos lados de la ecuación de montaje, todo debería ser genial.

Aclaración de la restricción de acceso:

Siento que debería poder montar cualquier cosa a la que el usuario tendría acceso en un punto de montaje del que es propietario.

Por ejemplo, en mi computadora / dev / sda1 es propiedad del usuario root y el disco de grupo con permisos brw-rw----. Por lo tanto, los usuarios no root no pueden meterse con / dev / sda1 y claramente mount no debería permitirles montarlo. Sin embargo, si el usuario posee /home/my_user/my_imagefile.img y punto de montaje / home / my_user / my_image / ¿por qué no deberían poder montar ese archivo de imagen en ese punto de montaje con:

mount /home/my_user/my_imagefile.img /home/my_user/my_image/ -o loop

Como señaló Kormac, hay un problema suid. Por lo tanto, tendrían que agregarse algunas restricciones para evitar que el suid sea un problema, así como potencialmente otros problemas. Quizás una forma de hacerlo sería hacer que el sistema operativo trate todos los archivos como pertenecientes al usuario que realizó el montaje. Sin embargo, para una simple lectura / escritura / ejecución, no veo por qué esto sería un problema.

Caso de uso:

Tengo una cuenta en un laboratorio donde el espacio de mi casa está restringido a 8 GB. Esto es pequeño y muy muy molesto. Me gustaría montar un volumen nfs desde mi servidor personal para aumentar esencialmente la cantidad de espacio que tengo. Sin embargo, debido a que Linux no permite tales cosas, estoy atascado con los archivos scp'ing de un lado a otro para permanecer por debajo del límite de 8 GB.

Es una restricción tanto histórica como de seguridad.

Históricamente, la mayoría de las unidades no eran extraíbles. Por lo tanto, tenía sentido restringir el montaje a las personas que tenían acceso físico legítimo, y probablemente tendrían acceso a la cuenta raíz. Las entradas fstab permiten a los administradores delegar el montaje a otros usuarios para unidades extraíbles.

Desde el punto de vista de la seguridad, existen tres problemas principales al permitir a los usuarios arbitrarios montar dispositivos de bloques arbitrarios o imágenes del sistema de archivos en ubicaciones arbitrarias.

• El montaje en una ubicación no propiedad sombrea los archivos en esa ubicación. Por ejemplo: monte un sistema de archivos de su elección /etc, que /etc/shadowcontenga una contraseña raíz que conozca. Esto se soluciona permitiendo que un usuario monte un sistema de archivos solo en el directorio que posee.
• Los controladores del sistema de archivos a menudo no se han probado tan a fondo con un sistema de archivos con formato incorrecto. Un controlador de sistema de archivos defectuoso podría permitir que un usuario que suministra un sistema de archivos con formato incorrecto inyecte código en el núcleo.
• Montar un sistema de archivos puede permitir que el montador haga que aparezcan algunos archivos que de otro modo no tendría permiso para crear. Archivos ejecutables y dispositivos setuid son los ejemplos más obvios, y que son fijados por los nosuidy nodevlas opciones que están implicados por tener useren /etc/fstab.
  Cumpliendo hasta ahora usercuandomountNo es llamado por root es suficiente. Pero, en general, poder crear un archivo propiedad de otro usuario es problemático: el contenido de ese archivo corre el riesgo de ser atribuido por el supuesto propietario en lugar del montador. Una copia casual de preservación de atributos por root a un sistema de archivos diferente produciría un archivo propiedad del propietario declarado pero no involucrado. Algunos programas verifican que una solicitud para usar un archivo sea legítima al verificar que el archivo es propiedad de un usuario en particular, y esto ya no sería seguro (el programa también debe verificar que los directorios en la ruta de acceso sean propiedad de ese usuario; Si se permitiera un montaje arbitrario, también tendrían que comprobar que ninguno de estos directorios es un punto de montaje donde el montaje no fue creado por el usuario root ni por el usuario deseado).

Para fines prácticos, hoy en día es posible montar un sistema de archivos sin ser root, a través de FUSE . Los controladores FUSE se ejecutan como el usuario de montaje, por lo que no hay riesgo de escalada de privilegios al explotar un error en el código del kernel. Los sistemas de archivos FUSE solo pueden exponer archivos que el usuario tiene permiso para crear, lo que resuelve el último problema anterior.

Si un usuario tiene acceso de escritura directo a un dispositivo de bloque y puede montar ese dispositivo de bloque, puede escribir un suid ejecutable en el dispositivo de bloque, montarlo y ejecutar ese archivo, y así obtener acceso de raíz al sistema. Es por eso que el montaje normalmente está restringido a la raíz.

Ahora la raíz puede permitir que los usuarios normales monten con restricciones específicas, pero debe asegurarse de que si el usuario tiene acceso de escritura al dispositivo de bloqueo, el montaje no permite suid, y también devnodes, que tienen un problema similar (el usuario puede crear un devnode que les da acceso de escritura a un dispositivo importante al que no deberían tener acceso de escritura).

No siempre requiere superprivs. Deman mount

   The non-superuser mounts.
          Normally,  only  the  superuser can mount filesystems.  However,
          when fstab contains the user option on a line, anybody can mount
          the corresponding system.

          Thus, given a line

                 /dev/cdrom  /cd  iso9660  ro,user,noauto,unhide

          any  user  can  mount  the iso9660 filesystem found on his CDROM
          using the command

                 mount /dev/cdrom

          or

                 mount /cd

          For more details, see fstab(5).  Only the user  that  mounted  a
          filesystem  can unmount it again.  If any user should be able to
          unmount, then use users instead of user in the fstab line.   The
          owner option is similar to the user option, with the restriction
          that the user must be the owner of the special file. This may be
          useful e.g. for /dev/fd if a login script makes the console user
          owner of this device.  The group option  is  similar,  with  the
          restriction  that  the  user  must be member of the group of the
          special file.

Kormac y otros han indicado que este no es el dilema como lo presentas; Me parece que esto se reduce a la filosofía de otorgar explícitamente privilegios a los usuarios frente a un sistema por el cual todos los usuarios tendrían el derecho inmutable de montar un sistema de archivos.

Gilles aborda algunos de los problemas de seguridad asociados con el montaje de sistemas de archivos. Evitaré retroactivamente una discusión prolongada y tangencial sobre posibles problemas técnicos relacionados con esto (ver comentarios), pero creo que es justo que los usuarios no confiables no tengan el derecho inmutable de montar discos duros.

El problema con respecto a los sistemas de archivos virtuales y remotos (o sistemas de archivos remotos a través de sistemas de archivos virtuales, a la FUSE) es menos significativo, pero esto no resuelve la cuestión de seguridad (aunque FUSE podría, y ciertamente resolvería su problema). También es importante tener en cuenta que casi siempre se puede acceder a los datos en dichos sistemas de archivos sin la necesidad de montar un dispositivo, ya sea mediante transferencia de archivos o herramientas que extraen de imágenes sin montar, por lo que un sistema que no le permite montar algo no representa un problema insuperable con respecto al acceso a los datos que ha colocado extrañamente en un archivo de imagen, o (más comprensiblemente) que desea obtener de un sistema remoto. Si tiene una situación en la que este no es el caso, puede valer la pena preguntar:

1. ¿Qué es exactamente lo que estoy tratando de hacer?

2. ¿Dónde estoy tratando de hacerlo?

Si la administración del sistema es justa, entonces # 2 explica por qué # 1 es imposible para usted. Si la administración del sistema no es justa, eso es política . La solución al problema, "Mi administrador de sistemas no es justo" no es rediseñar el sistema operativo para que los administradores de sistemas en todas partes no puedan restringir a los usuarios.

El sistema permite al superusuario restringir sus actividades, ya sea explícitamente o por omisión ("No proporcionamos FUSE", etc.). Los privilegios son un mecanismo mediante el cual esto se logra. Puede que no sea agradable que te digan: "No necesitas hacer esto", pero si es cierto ... que sera ... no necesitas hacer esto. Use ftp, etc. Si no es cierto, debería molestar a los responsables.

FYI: Los núcleos más nuevos tienen soporte para "espacio de nombres". Los usuarios comunes pueden crear un espacio de nombres, y dentro de ese espacio de nombres, convertirse root y hacer cosas divertidas como montar sistemas de archivos.

Sin embargo, no le otorga permisos de superusuario "reales": solo puede hacer lo que ya tiene permitido hacer (es decir, solo puede montar dispositivos que ya puede leer).

http://lwn.net/Articles/531114/ Ver sección 4.

Debido a que los datos en el sistema de archivos que intentan montar pueden comprometer la seguridad del servidor, o incluso bloquearlo (si se construyó intencionalmente de esa manera).

En GNOME, gvfs no requiere root para montar el sistema de archivos remoto (ftp o ssh) y gnome-mount tampoco necesita root para montar almacenamiento externo (unidad usb, CD / DVD, etc.).

La mayoría de los sistemas probablemente no querría tener toda la GNOME sólo para algunos montaje remoto, a continuación, puede utilizar LUFS , sshfs o ftpfs .

gvfs, lufs, sshfs y ftpfs usan FUSE para permitir que usuarios no root monten un sistema de archivos virtual; y, a diferencia de las monturas -o user, FUSE no requiere que el administrador del sistema organice monturas específicas. Siempre que tenga el privilegio para el directorio de montaje y los recursos necesarios para construir el sistema de archivos, puede crear el montaje FUSE.

¿Por qué Mount requiere privilegios de root?

Porque mountestá destinado principalmente / originalmente para el sistema de archivos local, que casi siempre involucra un hardware.