Чи можу я перенести дозволи користувачів на комп'ютери для зовнішнього жорсткого диска ext4?


16

У мене є зовнішній накопичувач USB 3 (ємністю 2 ТБ), який, швидше за все, буде переміщений з машини на машину. На диску є таблиця розділів GUID та розділ ext4. Я не можу записати на диск, якщо я не підвищую процес ( sudo).

На сьогоднішній день я думаю про те, щоб спробувати одне чи обидва з наступного, і хотів би знати мінуси кожного -

  1. chmod 777 /mnt/externalDrive
  2. chown nobody:nogroup /mnt/externalDrive

Якщо я даю дозвіл 777 і користувач пише його1 (UID: 1005), а пізніше переміщу диск на інший комп'ютер, де user7 - UID: 1005, що відбувається? Чи користувач7 стає власником файлу на цьому комп’ютері? Мені здається, що мені періодично доведеться бігати chown -R nobody:nogroup /mnt/externalDriveна диску.

Чи є щось із того, що я вважаю очевидною поганою практикою? Диск, швидше за все, буде містити відео, музику та зображення, жодне з них не потрібно захищати, як деякі фінансові дані.


Я не впевнений, чи слідкую за вами. Ви намагалися встановити дозволи на зовнішньому диску?
Рамеш

1
Так. Це гарна річ?
Лорд Лох.

Відповіді:


19

У цьому полягає проблема з багатокористувацькими системами, особливо якщо у вас є декілька з них. ;) Немає насправді приємного способу робити те, що ти хочеш. Підходи, що спадають на думку, були б

  • мати однаковий UID для свого облікового запису на всіх машинах, якими ви користуєтесь зовнішнім накопичувачем (насправді це неможливо, оскільки, швидше за все, не всі машини знаходяться під вашим контролем)
  • використання файлової системи, що не знає про конект власника / групи (FAT або NTFS, які приходять на думку, але ... ааа, ні)

Найефективнішим підходом було б повернення до загальних практик. У більшості (принаймні) систем Linux існує деякі групи, які зазвичай мають загальні GID. Наприклад users, який має GID 100на більшості дистрибутивів Linux. Якщо вам вдасться мати відповідний обліковий запис користувача у цій групі, ви могли б

  1. створіть усі файли та каталоги на своєму диску, що належать цій групі
  2. якось вдається мати відповідні групові дозволи на ці файли та каталоги
  3. якось вдається створити нові файли, створені відповідною груповою формою власності. дозволи.

Перший і другий пункт легко виконати ( chown, chmod). Третя точка стає трохи складнішою.

Частина "групового володіння" відносно проста: ви можете встановити біт SGID у всіх каталогах на диску. Біт SGID, застосований до каталогів, вказує на те, що ядро ​​поводиться BSDish: BSD робить кожен файл / каталог, створений під певною групою каталогів, не належить основній групі процесу створення файлу / каталогу (як це робить Linux), власником батьківського каталогу.

Біт дозволу трохи важкий. На дозвіл новостворених файлів / каталогів (серед інших) впливає umask, бітова маска, яка вказує, які біти не встановлювати, якщо явно не зазначено. Наприклад, загальне umaskзначення полягає в тому 022, що біти запису для "групи" та "інших" зазвичай не слід встановлювати. Ви можете змінити umaskна 002, сказавши, що не хочете, щоб дозволи на запис видалялися для групи, але недоліком є ​​те, що ви не можете встановити цей каталог на основі значень і зазвичай не хочете мати дозволу на запис для ваш основний набір груп для кожного створеного файлу.

Це може бути вирішена з допомогою списків управління доступом: В ACL ви можете встановити maskі defaultнабір дозволів, який застосовується до всіх файлів і каталогів , створених усередині каталогу з цим набором ACL. Отже, одним із можливих варіантів вирішення вашої проблеми було б

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

Дивіться setfacl(1)та acl(5)для отримання більш детальної інформації.


1
Навколо нього плавав патч для його та gid картографування у ext4, spinics.net/lists/linux-fsdevel/msg57240.html , але я не думаю, що він пережив ...
Rmano

11

Там є ще одне подібне запитання, і там пропонується прив'язка:

mkdir /home/$user/sda1
bindfs -u $user -g $group /mnt/sda1 /home/$user/sda1

Користувачі OSX пропонують noownersваріант монтажу описаний так:

Ігноруйте поле власності на весь том. Це призводить до того, що всі об'єкти відображаються як власники ідентифікатора користувача 99 та ідентифікатора групи 99. ID користувача 99 інтерпретується як поточний ефективний ідентифікатор користувача, тоді як ідентифікатор групи 99 використовується безпосередньо та перекладається на "невідомий".


bindfs досить повільний. Можливо, тому, що це файлова система FUSE.
Навін

4

Власник і група файлу зберігаються як числа. Таким чином, файлом належить uid = 1005, незалежно від того, до якого користувача (або його немає взагалі), до якого він підключений.

Зміна користувача / групи нікому не вирішить вашу проблему. Тоді тільки нікому користувачеві (або членам групи "ніхто") було б дозволено отримати доступ до файлів.

На жаль, я не думаю, що існує спосіб відключити перевірку дозволів на ext4. Дивіться, наприклад, чи можна відключити дозволи файлів у файловій системі ext3 або ext4?


2

Андреас Візе каже, що якщо у вас є загальний ідентифікатор групи у всіх хостів, ви можете вирішити свою проблему за допомогою setgidбіта та ACL

Я задаю питання Заздалегідь визначені ідентифікатори групи в дистрибутивах Linux?

Після власних досліджень встановлено, що така група існує у всіх дотикових дистрибутивах: sysгруповий ідентифікатор обміну 3на Debian, Ubuntu, RedHat, Fedora, CentOS, Suse, FreeBSD, OpenBSD, NetBSD, MacOSX, Solaris.

З цим:

$ sudo chgrp -R sys /mnt/data/dir
$ sudo chmod -R g+s /mnt/data/dir
$ sudo setfacl -R -m g:sys:rwx /mnt/data/dir
$ sudo setfacl -R -d -m g:sys:rwx /mnt/data/dir

і аромат цього:

$ sudo adduser user sys

ви userможете читати / писати будь-який файл на /dir.

Більшість робіт може робити setgidтрохи, але, на жаль, у вас зазвичай мало контролю umask. Таким чином, ACL використовується для забезпечення повного рішення.

Дивись також:

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.