Pourquoi mount requiert-il des privilèges root?

Pourquoi Linux exige-t-il qu'un utilisateur soit root / en utilisant sudo / spécifiquement autorisé par montage pour pouvoir monter quelque chose? Il semble que la décision d'autoriser un utilisateur à monter quelque chose doit être basée sur ses droits d'accès au volume source / partage réseau et au point de montage. Deux utilisations possibles du montage non root sont le montage d'images de système de fichiers dans une direction appartenant à l'utilisateur et le montage d'un partage réseau dans un répertoire appartenant à l'utilisateur. Il semble que si l'utilisateur a le contrôle des deux côtés de l'équation de montage, tout devrait être cool.

Clarification de la restriction d'accès:

J’estime que je devrais pouvoir monter tout ce que l’utilisateur aurait autrement accès à un point de montage dont il est le propriétaire.

Par exemple, sur mon ordinateur, / dev / sda1 appartient à l'utilisateur root et au disque de groupe avec autorisations brw-rw----. Par conséquent, les utilisateurs non root ne peuvent pas jouer avec / dev / sda1 et clairement, mount ne devrait pas leur permettre de le monter. Toutefois, si l'utilisateur possède /home/my_user/my_imagefile.img et le point de montage / home / mon_utilisateur / mon_image / pourquoi ne devrait-il pas pouvoir monter ce fichier image sur ce point de montage avec:

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

Comme l'a souligné Kormac, il existe un problème suid. Il faudrait donc ajouter certaines restrictions pour éviter que le suid ne soit un problème, ainsi que potentiellement d’autres problèmes. Une façon de procéder serait peut-être de faire en sorte que le système d'exploitation traite tous les fichiers comme appartenant à l'utilisateur qui a effectué le montage. Cependant, pour une lecture / écriture / exécution simple, je ne vois pas pourquoi cela poserait un problème.

Cas d'utilisation:

J'ai un compte dans un laboratoire où l'espace de mon domicile est limité à 8 Go. C'est minuscule et très très énervant. Je souhaite monter un volume nfs à partir de mon serveur personnel pour augmenter sensiblement le volume d'espace disponible. Cependant, comme Linux ne permet pas à de telles choses, je suis coincé avec les fichiers scp'ing dans les deux sens pour rester sous la limite de 8 Go.

C'est à la fois une restriction historique et de sécurité.

Historiquement, la plupart des lecteurs n'étaient pas amovibles. Il était donc logique de limiter le montage aux personnes ayant un accès physique légitime et qui auraient probablement accès au compte root. Les entrées fstab permettent aux administrateurs de déléguer le montage aux autres utilisateurs pour les lecteurs amovibles.

Du point de vue de la sécurité, permettre à des utilisateurs arbitraires de monter des périphériques de blocs ou des images de système de fichiers à des emplacements arbitraires pose trois problèmes majeurs.

• Le montage sur un emplacement n'appartenant pas au propriétaire masque les fichiers à cet emplacement. Par exemple: montez un système de fichiers de votre choix /etcavec un /etc/shadowmot de passe root que vous connaissez. Ceci est corrigé en permettant à un utilisateur de monter un système de fichiers uniquement sur un répertoire qu'il possède.
• Les pilotes de système de fichiers n'ont souvent pas été testés de manière aussi approfondie avec un système de fichiers mal formé. Un pilote de système de fichiers défectueux pourrait permettre à un utilisateur fournissant un système de fichiers mal formé d’injecter du code dans le noyau.
• Monter un système de fichiers peut permettre au monteur de faire apparaître certains fichiers qu'il n'aurait autrement pas la permission de créer. Exécutables setuid et fichiers appareil sont les exemples les plus évidents, et ils sont fixés par les nosuidet les nodevoptions qui sont sous - entendus en ayant userdans /etc/fstab.
  Jusqu'ici en vigueur userquandmountn'est pas appelé par root est suffisant. Mais plus généralement, pouvoir créer un fichier appartenant à un autre utilisateur est problématique: le contenu de ce fichier risque d’être attribué au prétendu propriétaire au lieu du monteur. Une copie occasionnelle préservant les attributs par root sur un système de fichiers différent produirait un fichier appartenant au propriétaire déclaré, mais non impliqué. Certains programmes vérifient que la demande d'utilisation d'un fichier est légitime en vérifiant que le fichier appartient à un utilisateur particulier et que cela ne serait plus sans danger (le programme doit également vérifier que les répertoires du chemin d'accès appartiennent à cet utilisateur; si le montage est autorisé de manière arbitraire, ils devront également vérifier qu'aucun de ces répertoires n'est un point de montage où le montage n'a été créé ni par root ni par l'utilisateur souhaité).

Pour des raisons pratiques, il est aujourd'hui possible de monter un système de fichiers sans être root, via FUSE . Les pilotes FUSE s'exécutant en tant qu'utilisateur en montage, il n'y a donc aucun risque d'élévation des privilèges en exploitant un bogue du code du noyau. Les systèmes de fichiers FUSE peuvent uniquement exposer les fichiers que l'utilisateur est autorisé à créer, ce qui résout le dernier problème mentionné ci-dessus.

Si un utilisateur a un accès direct en écriture à un périphérique bloc et peut monter ce périphérique bloc, il peut alors écrire un exécutable suid sur le périphérique bloc, le monter et l'exécuter, afin d'obtenir un accès root au système. C'est pourquoi le montage est normalement limité à la racine.

Maintenant, root peut autoriser les utilisateurs normaux à monter avec des restrictions spécifiques, mais il doit s’assurer que si l’utilisateur a un accès en écriture sur le périphérique bloc, le montage interdit le suid, ainsi que devnode, qui ont un problème similaire (l’utilisateur peut devnode qui leur donne un accès en écriture à un périphérique important auquel ils ne devraient pas avoir accès en écriture).

Il ne nécessite pas toujours de super privs. 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 et d’autres ont indiqué que ce n’était pas le dilemme que vous présentez. il me semble que cela revient à la philosophie qui consiste à accorder explicitement des privilèges utilisateur à un système dans lequel tous les utilisateurs auraient le droit immuable de monter un système de fichiers.

Gilles résout certains des problèmes de sécurité associés au montage de systèmes de fichiers. J'éviterai rétroactivement une discussion prologue et tangentielle sur des problèmes techniques potentiels liés à ce problème (voir commentaires), mais j'estime qu'il est juste que les utilisateurs non fiables ne disposent pas d'un droit immuable de monter des disques durs.

Le problème concernant les systèmes de fichiers virtuels et distants (ou les systèmes de fichiers distants via des systèmes de fichiers virtuels à la FUSE) est moins important, mais cela ne résout pas la question de la sécurité (bien que FUSE puisse le faire, cela résoudrait certainement votre problème). Il est également important de noter que les données de tels systèmes de fichiers sont presque toujours accessibles sans montage de périphérique, que ce soit par transfert de fichiers ou par des outils permettant d'extraire des images sans montage. Par conséquent, un système qui ne vous permet pas de monter pas un problème insurmontable en ce qui concerne l’accès aux données que vous avez bizarrement placées dans un fichier image, ou (plus compréhensible) que vous souhaitez obtenir d’un système distant. Si vous avez une situation où ce n'est pas le cas, cela vaut la peine de demander:

1. Qu'est-ce que j'essaie de faire exactement?

2. Où est-ce que j'essaie de le faire?

Si l'administration du système est équitable, alors la n ° 2 explique pourquoi la n ° 1 vous est impossible. Si l'administration du système n'est pas juste, c'est de la politique . La solution au problème, "Mon administrateur système n'est pas juste" ne consiste pas à redéfinir le système d'exploitation, de sorte que les administrateurs système de partout ne puissent pas restreindre les utilisateurs.

Le système permet au super utilisateur de restreindre vos activités, soit explicitement, soit par omission ("Nous ne fournissons pas de FUSE", etc.). Les privilèges sont un mécanisme par lequel cela est accompli. Ce n'est peut-être pas agréable de se faire dire: "Vous n'avez pas besoin de faire ça", mais si c'est vrai ... que sera ... vous n'avez pas besoin de faire ça. Utilisez ftp, etc. Si ce n'est pas vrai, vous devriez harceler les responsables.

FYI: Les nouveaux noyaux ont un support "namespace". Les utilisateurs ordinaires peuvent créer un espace de noms et, au sein de celui-ci, devenir root et faire des choses amusantes telles que le montage de systèmes de fichiers.

Cela ne vous donne cependant pas de "vraies" autorisations de super-utilisateurs - vous ne pouvez faire que ce que vous êtes déjà autorisé à faire (c.-à-d. Que vous ne pouvez monter que des périphériques que vous pouvez déjà lire).

http://lwn.net/Articles/531114/ Voir section 4.

Parce que les données sur le système de fichiers qu'ils ont l'intention de monter risquent de compromettre la sécurité du serveur, voire de le faire planter (s'il a été construit intentionnellement de cette façon).

Dans GNOME, gvfs n’a pas besoin de root pour monter un système de fichiers distant (ftp ou ssh) et gnome-mount n’a pas non plus besoin de root pour monter un stockage externe (lecteur USB, CD / DVD, etc.).

La plupart des systèmes ne voudront probablement pas disposer de GNOME dans son intégralité uniquement pour un montage distant, vous pouvez alors utiliser lufs , sshfs ou ftpfs .

gvfs, lufs, sshfs et ftpfs utilisent FUSE pour permettre aux utilisateurs non root de monter un système de fichiers virtuel; et contrairement à mount -o user, FUSE n’a pas besoin de l’administrateur système pour organiser des montages spécifiques. Tant que vous avez le privilège de disposer du répertoire de montage et des ressources nécessaires pour construire le système de fichiers, vous pouvez créer un montage FUSE.

Pourquoi mount requiert-il des privilèges root?

Car mountest principalement / initialement destiné au système de fichiers local, qui implique presque toujours un matériel.