Чому для монтажу потрібні привілеї root?

Чому для Linux потрібен користувач root / використовує sudo / спеціально уповноважений на кожну версію, щоб щось змонтувати? Схоже, рішення про те, чи дозволяти користувачеві змонтувати щось, має ґрунтуватися на їхніх правах доступу до вихідного об'єму / спільної мережі та до точки монтування. Кілька застосувань для некореневого монтажу - це встановлення зображень файлової системи у напрямку, що належать користувачеві, та встановлення мережевої папки до каталогу, що належить користувачеві. Схоже, якщо користувач має контроль над обома сторонами рівняння монтування, все має бути крутим.

Пояснення обмеження доступу:

Я вважаю, що я повинен мати змогу встановити все, до чого користувач в іншому випадку матиме доступ до точки монтажу, власником якої є користувач.

Наприклад, на моєму комп’ютері / dev / sda1 належить користувальницький кореневий та груповий диск з дозволами brw-rw----. Тому не-root користувачі не можуть возитися з / 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, існує суїдська проблема. Тому деякі обмеження повинні бути додані, щоб запобігти виникненню суїдської проблеми, а також можливих інших проблем. Можливо, одним із способів цього було б зробити так, щоб ОС розглядала всі файли як належні користувачеві, який здійснив встановлення. Однак для простого читання / запису / виконання, я не бачу, чому це буде проблемою.

Корпус:

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

Це як історичне, так і обмеження безпеки.

Історично більшість дисків не було знімним. Тож має сенс обмежувати встановлення доступу до людей, які мали законний фізичний доступ, і вони, ймовірно, матимуть доступ до кореневого облікового запису. Записи fstab дозволяють адміністраторам делегувати монтаж іншим користувачам для знімних дисків.

З точки зору безпеки, існують три основні проблеми із дозволом довільним користувачам монтувати довільні блоки пристроїв або зображень файлової системи у довільних місцях.

• Якщо встановити місце, яке не належить, затінює файли в цьому місці. Наприклад: встановіть файлову систему на ваш вибір /etcіз /etc/shadowвмістом кореневого пароля, який ви знаєте. Це виправлено, дозволяючи користувачеві монтувати файлову систему лише в каталозі, який йому належить.
• Драйвери файлової системи часто не перевіряються настільки ретельно з неправильно сформованою файловою системою. Помилковий драйвер файлової системи може дозволити користувачеві, який постачає неправильну файлову систему, вводити код у ядро.
• Монтаж файлової системи може дозволити майстру викликати появу деяких файлів, які він інакше не мав би дозволу на створення. Setuid виконувані і пристрій файлів є найбільш очевидними прикладами, і вони фіксуються з допомогою nosuidі nodevопцій , які маються на увазі, маючи userв /etc/fstab.
  До сих пір в житті , userколиmountне називається коренем достатньо. Але в більш загальному випадку створити файл, який належить іншому користувачеві, проблематично: вміст цього файлу ризикує бути припишеним передбачуваним власником замість програвача. Випадкова копія, що зберігає атрибут, коренем до іншої файлової системи, створює файл, що належить власнику, який оголосив, але не включений. Деякі програми перевіряють, що запит на використання файлу є законним, перевіряючи, чи належить певному користувачеві файл, і це більше не є безпечним (програма також повинна перевірити, що каталоги на шляху доступу належать цьому користувачеві; якщо дозволено довільне встановлення, вони також повинні будуть перевірити, що жоден із цих каталогів не є точкою монтажу, де монтаж створений ні коренем, ні потрібним користувачем).

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

Якщо користувач має прямий доступ для запису на блоковий пристрій і може змонтувати цей блоковий пристрій, він може записати виконаний suid на блоковий пристрій, змонтувати його, виконати цей файл і, таким чином, отримати кореневий доступ до системи. Ось чому монтаж зазвичай обмежується коренем.

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

Це не завжди вимагає суперпривітів. З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.

Кормач та інші вказали, що це не та дилема, яку ви представляєте як; мені здається, це зводиться до філософії явного надання користувачеві привілеїв порівняно з системою, згідно з якою всі користувачі мали б незмінне право монтувати файлову систему.

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

Проблема щодо віртуальних та віддалених файлових систем (або віддалених файлових систем через віртуальні файлові системи, a la FUSE) менш важлива, але це не вирішує питання безпеки (хоча FUSE може, і це, безумовно, вирішить вашу проблему). Важливо також врахувати, що до даних у таких файлових системах можна майже завжди отримати доступ без необхідності монтажу пристрою, або через передачу файлів, або інструменти, які витягують із зображень без монтажу, тому система, яка не дозволяє вам щось монтувати, робить не представляє непереборної проблеми щодо доступу до даних, які ви химерно розмістили у файлі зображення, або (що більш зрозуміло) хочете отримати з віддаленої системи. Якщо у вас є ситуація, коли це не так, можливо, варто запитати:

1. Що саме я намагаюся зробити?

2. Де я намагаюся це зробити?

Якщо адміністрування системи справедливе, то №2 пояснює, чому №1 для вас неможливий. Якщо адміністрування системи не є справедливим, це політика . Рішення проблеми "Мій системний адміністратор не справедливий" - не переробляти ОС, щоб системні адміністратори скрізь не могли обмежувати користувачів.

Система дозволяє суперкористувачеві обмежувати вашу діяльність, явно, або шляхом пропуску ("Ми не надаємо ФУЗЕ" тощо). Пільги - це один із механізмів, завдяки якому це здійснюється. Можливо, це не приємно сказати: "Вам цього не потрібно робити", але якщо це правда ... que sera ... вам цього не потрібно робити. Використовуйте ftp і т. Д. Якщо це неправда, слід домагатися відповідальних.

FYI: Найновіші ядра мають підтримку "простору імен". Звичайні користувачі можуть створювати простір імен, і всередині цього простору імен ставати root та робити забавні речі, як монтувати файлові системи.

Однак це не дає "справжніх" дозволів для суперкористувача - ви можете робити лише те, що вам уже дозволено (тобто ви можете монтувати лише ті пристрої, які ви вже можете читати).

http://lwn.net/Articles/531114/ Див. розділ 4.

Оскільки дані про файлову систему, яку вони мають намір встановити, можуть поставити під загрозу безпеку сервера або навіть розбити його (якщо це було навмисно побудовано таким чином).

У GNOME gvfs не потребує root для монтажу віддаленої файлової системи (ftp або ssh), а також gnome-mount також не потребує root для монтажу зовнішнього сховища (USB-накопичувач, CD / DVD тощо).

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

gvfs, lufs, sshfs та ftpfs використовує FUSE, щоб дозволити користувачам, що не мають root, змонтувати віртуальну файлову систему; і на відміну від монтажу -o user, FUSE не вимагає, щоб sysadmin влаштовував конкретні кріплення. Поки ви маєте привілей для каталогу mount і до будь-яких ресурсів, необхідних для побудови файлової системи, ви можете створити FUSE mount.

Чому для монтажу потрібні привілеї root?

Тому що mountв першу чергу / спочатку призначений для локальної файлової системи, яка майже завжди включає апаратне забезпечення.