Почему действительно монтируется, требуют полномочий пользователя root?

Почему Linux требует, чтобы пользователь был корнем/использованием sudo/specifically авторизованный на монтирование для монтирования чего-то? На решение относительно того, походит, позволить ли пользователю монтировать, что что-то должно быть основано на их правах доступа к исходному объему/сетевому ресурсу и к точке монтирования. Несколько использования для некорневого монтирования монтируют изображения файловой системы к пользовательскому направлению и монтируют сетевой ресурс к пользовательскому каталогу. Походит, если пользователь управляет обеими сторонами уравнения монтирования, все должно быть прохладным.

Разъяснение ограничения доступа:

Я чувствую, что должен смочь смонтировать что-либо, к чему у пользователя иначе был бы доступ к точке монтирования, из которой пользователь является владельцем.

Например, на моем компьютере/dev/sda1 принадлежит пользовательскому корню и диску группы с полномочиями brw-rw----. Поэтому некорневые пользователи не могут смешать с/dev/sda1, и ясно монтирование не должно позволять им монтировать его. Однако, если пользователь владеет/home/my_user/my_imagefile.img и точкой монтирования/home/my_user/my_image/, почему не был должен они смочь смонтировать что файл изображения на той точке монтирования с:

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

Поскольку kormac указал, там suid проблема. Таким образом, некоторые ограничения должны были бы быть добавлены, чтобы препятствовать тому, чтобы suid был проблемой, а также потенциально некоторыми другими проблемами. Возможно, один способ сделать это должно было бы заставить ОС рассматривать все файлы как принадлежащий пользователю, который сделал монтирование. Однако для простого читал/писал/выполнял, я не вижу, почему это было бы проблемой.

Вариант использования:

У меня есть учетная запись в лаборатории, где мое домашнее пространство ограничивается 8 ГБ. Это является крошечным и очень очень раздражающим. Я хотел бы смонтировать объем nfs со своего персонального сервера для важного увеличения суммы комнаты, которую я имею. Однако, потому что Linux не позволяет такие вещи, я застреваю с scp'ing файлами назад и вперед для пребывания под пределом на 8 ГБ.

54
17.02.2013, 14:36
7 ответов

Это - и историческое и ограничение безопасности.

Исторически, большинство дисков не было съемным. Таким образом, имело смысл ограничивать монтирование людьми, у которых был законный физический доступ, и у них, вероятно, будет доступ к корневой учетной записи. fstab записи позволяют администраторам делегировать монтирование другим пользователям для съемных дисков.

С точки зрения безопасности существует три основных проблемы с разрешением произвольным пользователям смонтировать произвольные блочные устройства или изображения файловой системы в произвольных местоположениях.

  • Монтирование к ненаходящемуся в собственности местоположению тени файлы в том местоположении. Например: смонтируйте файловую систему по Вашему выбору на /etc, с /etc/shadow содержа пароль root, который Вы знаете. Это фиксируется, позволяя пользователю смонтировать файловую систему только на каталоге, которым он владеет.
  • Драйверы файловой системы часто не тестировались как полностью с уродливой файловой системой. Ошибочный драйвер файловой системы мог позволить пользователю, предоставляющему уродливую файловую систему вводить код в ядро.
  • Монтирование файловой системы может позволить mounter заставлять некоторые файлы появляться, что у него иначе не было бы разрешения создать. Исполняемые файлы Setuid и файлы устройств являются самыми очевидными примерами, и они фиксируются nosuid и nodev опции, которые подразумеваются при наличии user в /etc/fstab.
    До сих пор осуществление user когда mount не назван корнем, достаточно. Но в более общем плане способность создать файл, принадлежавший другому пользователю, проблематична: содержание того файла рискует приписываться подразумеваемым владельцем вместо mounter. Случайная сохраняющая атрибут копия корнем к другой файловой системе произвела бы файл, принадлежавший объявленному-но-невключенному владельцу. Некоторые программы проверяют, что запрос для использования файла является легальным путем проверки, что файл принадлежит конкретному пользователю, и это больше не было бы безопасно (программа должна также проверить, что каталоги на пути доступа принадлежат тому пользователю; если бы произвольное монтирование было позволено, то они должны были бы также проверить, что ни один из этих каталогов не точка монтирования, где монтирование не было создано ни корнем, ни требуемым пользователем).

Практически, возможно в наше время смонтировать файловую систему, не будучи корнем через FUSE. Драйверы FUSE работают как монтирующийся пользователь, таким образом, нет никакого риска расширения полномочий путем использования ошибки в коде ядра. Файловые системы FUSE могут только выставить файлы, которые у пользователя есть разрешение создать, который решает последнюю проблему выше.

37
27.01.2020, 19:33

Если пользователь имеет прямой доступ для записи к блочному устройству и может смонтировать, что блочное устройство, то они могут записать suid исполняемый файл в блочное устройство, монтируется, оно, и выполняет тот файл, и таким образом, получает корневой доступ к системе. Поэтому монтирование обычно ограничивается корнем.

Теперь корень может позволить обычным пользователям монтироваться с определенными ограничениями, но он должен удостовериться что, если у пользователя есть доступ для записи к блочному устройству, что монтирование запрещает suid, и также devnodes, которые имеют подобную проблему (пользователь может обработать devnode, который дает им доступ для записи к важному устройству, у них не должно быть доступа для записи к).

24
27.01.2020, 19:33

Это не всегда требует супер privs. От man 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.
8
27.01.2020, 19:33
  • 1
    Да, Вы корректны, я был немного неточен в своем вопросе. Я знаю, что можно быть конкретно авторизован на mount-mount основе. Но кажется, принадлежат ли точка монтирования и объем оба пользователю, которого пользователь должен смочь смонтировать без определенной авторизации. –   17.02.2013, 02:39
  • 2
    @CrazyCasta: точка монтирования может принадлежать пользователю, но узел устройства не. То, что владения, и т.д., находятся на данных в разделе, непостижимо a) непостижимый, b) не важный. –  goldilocks 17.02.2013, 02:52
  • 3
    Но что, если узел устройства принадлежит пользователю. –  CrazyCasta 17.02.2013, 03:56
  • 4
    Затем должно быть параллельное исключение, сделанное в fstab, так как пользовательский узел устройства был бы исключительным для запуска с (попытайтесь создать один). Снова, принцип - то, что защищенная система ограничивается, и людям предоставляют полномочия..., если Вам не предоставили полномочия, Вам не повезло, к сожалению. Посмотрите, *отклоняют, не продает журналы большой емкости законно - Вам нужно разрешение. –  goldilocks 17.02.2013, 04:01
  • 5
    быть ясными, mount() системный вызов всегда требует корня. утилиты suid могут стать корнем и позволить не пользователям root монтироваться, и если mount команда установлена suid, затем это сделает это на основе пользовательского флага в fstab. Другие suid исполняемые файлы были записаны, чтобы позволить пользователям монтироваться, такой как pmount, который позволяет пользователям монтировать внешние медиа и осуществляет соответствующие ограничения, такие как nosuid, nodev. –  psusi 17.02.2013, 20:13

Kormac и другие указали, что это не дилемма, Вы представляете его как; это кажется мне, это сводится к философии явного предоставления пользовательских полномочий по сравнению с системой, посредством чего все пользователи имели бы неизменное право смонтировать файловую систему.

Gilles обращается к некоторым проблемам безопасности, связанным с монтированием файловых систем. Я задним числом избегу prologed и тангенциальной дискуссии о потенциальных технических вопросах, связанных с этим (см. комментарии), но я действительно думаю, что справедливо, что недоверяемые пользователи не имеют неизменное право смонтировать жесткие диски.

Проблема относительно виртуальных файловых систем и удаленных файловых систем (или удаленных файловых систем через виртуальные файловые системы, а-ля FUSE) является менее значительной, но это не решает вопрос о безопасности (хотя FUSE мог бы, и это, конечно, решит Вашу проблему). Также важно полагать, что к данным в таких файловых системах можно почти всегда получать доступ без потребности в монтировании устройства, или посредством передачи файлов или посредством инструментов, которые извлекают из изображений без монтирования, таким образом, система, которая не позволяет Вам монтировать что-то, не представляет непреодолимую проблему относительно доступа к данным, которые Вы причудливо поместили в файл изображения или (более понятно) хотите добраться от удаленной системы. Если у Вас есть ситуация, где дело обстоит не так, могло бы иметь смысл спрашивать:

  1. Что это точно, я пытаюсь сделать?

  2. Где я пытаюсь сделать это?

Если администрирование системы справедливо, то № 2 объясняет, почему № 1 невозможен для Вас. Если администрирование системы не справедливо, это - политика. Решение проблемы, "Мой sys администратор не справедлив", не состоит в том, чтобы перепроектировать ОС так, чтобы sys администраторы везде не могли ограничить пользователей.

Система позволяет суперпользователю ограничивать Ваши операции, или явно, или пропуском ("Мы не обеспечиваем FUSE", и т.д.). Полномочия являются одним механизмом, посредством которого это выполняется. Не может быть хорошо быть сказанным, "Вы не должны делать этого", но если это верно... que сыворотки... Вы не должны делать этого. Используйте ftp и т.д. Если это не верно, необходимо пристать к ответственным.

5
27.01.2020, 19:33
  • 1
    Ваш ответ сбивает с толку, не сами объемы (например,/dev/sda1,/dev/sda2, и т.д.) защищенный от пользователей, читающих/пишущих их? Я задаюсь вопросом, почему пользователь не может смонтировать что-то, к чему у них иначе есть доступ. Для разъяснения если у меня есть файл изображения, это, говорят, что ext2, который я мог бы записать приложению, которое позволяет мне чтению-записи из/в упомянутое изображение (не как часть файловой системы ОС, конечно). Упомянутое приложение не смогло бы к чтению-записи от разделов в/dev (если те разделы не были изменены, чтобы предоставить пользовательский доступ им, который обычно не имеет смысла). –  CrazyCasta 17.02.2013, 03:27
  • 2
    P.S. Я не соглашаюсь, что пользователи должны смочь смонтировать файловую систему, к которой у них иначе нет доступа без определенной авторизации с тех пор просто действие монтирования, что это могло потенциально вызвать своего рода действие (как проверка файловой системы), что корень не хотел. –  CrazyCasta 17.02.2013, 03:36
  • 3
    Монтирование изображения все еще включает узлы устройства (например,/dev/loop). Вы правы, что это создает стычку, но "принимающий меры" для этого собирается варьироваться от системы до системы (существует конечное предоставление циклических устройств, с одной стороны), поэтому снова, вот почему по умолчанию это все ограничивается. Но то значение по умолчанию еще может все еще быть переопределено, суперпользователем, от имени кто бы ни. –  goldilocks 17.02.2013, 03:36
  • 4
    Это - положительная сторона у предела узлов устройства закольцовывания. Я не действительно ясен, почему должно быть устройство закольцовывания, хотя, кажется немного избыточным. Я знаю, что это - потому что монтирование требует мудрого блоком файла скорее затем нормальный файл. Я не понимаю, почему это все же. Можно ли предложить понимание, как ядро рассматривает блочные устройства и регулярные файлы значительно по-другому? –  CrazyCasta 17.02.2013, 03:50
  • 5
    @goldilocks: причина этот ответ является яйцами, состоит в том, потому что Ваша теория позади ограничения очень убедительна, но это полностью неправильно, проблема, которую Вы упомянули, не существует. Разрешение создания виртуальной файловой системы (как FUSE) не позволяет Вам делать что-либо, что не уже возможно в больше окольном способе использовать IPC. Ваше примечание относительно прерываний на устройствах полностью не важно; единственное значительное прерывание, которое происходит на для удаленной файловой системы, прибывает из сетевой платы, которые обрабатываются полностью ядром. –  Lie Ryan 17.02.2013, 17:31

К вашему сведению: новейшие ядра имеют поддержку "пространства имен". Обычные пользователи могут создать пространство имен, и в том пространстве имен, стать root и сделайте забавному материалу нравится, монтируют файловые системы.

Это не дает Вам "реальные" полномочия суперпользователя, хотя - можно только сделать то, что Вам уже разрешают сделать (т.е. можно только смонтировать устройства, которые можно уже считать).

Раздел http://lwn.net/Articles/531114/ See 4.

5
27.01.2020, 19:33

Поскольку данные по файловой системе, которую они намереваются смонтировать, могли бы поставить под угрозу безопасность сервера или даже разрушить его (если бы это было намеренно создано тот путь).

0
27.01.2020, 19:33
  • 1
    Вы могли уточнить? Я не уверен, как "данные по файловой системе они намереваются смонтироваться", поставил бы под угрозу безопасность. Если Вы можете чтение-запись файл обычно затем, необходимо смочь смонтироваться, это (мой аргумент). Если я могу чтение-запись точка монтирования затем, я должен смочь ко всему, что монтирование может за исключением фактического монтирования его к каталогу. Если Вы не можете чтение-запись это или не можете просмотреть каталог, это находится в видеть, существует ли это затем, монтирование просто привело бы к сбою таким же образом ls, или команда типа кошки была бы. –   17.02.2013, 02:45
  • 2
    Ваш аргумент допустим, если 'Вы' - отдельный пользователь; помните, что Linux (и Unix) является многопользовательскими системами, где пользователям не обязательно доверяют. двоичные файлы –  sendmoreinfo 17.02.2013, 02:54
  • 3
    suid могли быть добавлены к устройству, смонтировались на Вашем поле и раньше базировались поле, которое является почему по умолчанию owner и user(s) набор nosuid. Вы не хотели бы кого-то способность обойти это легко с разрешением им вручную удалить nosuid –  R. S. 17.02.2013, 03:05
  • 4
    @sendmoreinfo я хорошо знаю, что Linux является многопользовательской системой, нет никакой потребности быть покровительственным. Я задаюсь вопросом, почему я ограничиваюсь в монтировании сетевых ресурсов и файлов изображений, что у меня иначе есть много доступа. ответ kormoc освещает, хотя мне любопытно, почему определенные флаги не могли быть вынуждены на некорневых пользователях (как nosuid) зафиксировать это. Кажется, что я должен смочь смонтировать в целях простого чтения-записи файл изображения / сетевой ресурс, к которому у меня иначе есть доступ на точку монтирования, которой я владею. –  CrazyCasta 17.02.2013, 03:23
  • 5
    @CrazyCasta WRT "создание системного катастрофического отказа", конечно, возможно смонтировать неисправное оборудование, которое использует уязвимости в аппаратном интерфейсе. Любой, у кого был жесткий диск с достаточным количеством сбойных блоков на нем, может сказать Вам, как это может влиять на ядро (и следовательно целая система) - это входит в занятый цикл и эффективно парализует целый набор и компанию. Существует, по-видимому, некоторая логика в корне того, что лишает возможности решать, так как это - известная проблема, которая существовала в течение долгого времени без решения. –  goldilocks 17.02.2013, 03:48

В GNOME gvfs не требует, поддерживают монтирование удаленной файловой системы (ftp или ssh) и монтируются гном, также не должен поддерживать монтирование внешнего устройства хранения данных (карта памяти, CD/DVD, и т.д.).

Большинство систем, вероятно, не хотело бы иметь целый GNOME только для некоторого удаленного монтирования, затем можно использовать наветренные стороны, sshfs или ftpfs.

gvfs, наветренные стороны, sshfs, и ftpfs используют FUSE, чтобы позволить некорневым пользователям монтировать виртуальную файловую систему; и в отличие от монтирования -o user, FUSE не требует, чтобы системный администратор расположил определенное монтирование. Пока у Вас есть полномочие для каталога монтирования и к любым ресурсам, которые необходимы для построения файловой системы, можно создать FUSE, монтируются.

Почему действительно монтируется, требуют полномочий пользователя root?

Поскольку mount прежде всего/первоначально, предназначается для локальной файловой системы, которая почти всегда включает аппаратные средства.

0
27.01.2020, 19:33

Теги

Похожие вопросы