Хороший і простий спосіб обміну файлами на локальній машині


13

Я хотів би мати каталог, який має такі властивості:

  • Багато користувачів можуть копіювати файли в нього
  • Ці файли можуть бути видалені / змінені цими користувачами (користувач A може видалити / змінити файл, скопійований у цей каталог)

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

Ось що я знайшов у мережі:

Деякі випадки використання:

  • Обмін музикою на локальній машині
  • Просте спільне використання сховища git (просто зробіть голий сховище доступним для багатьох людей) --- я знаю, що є такі рішення, як gitosis
  • Дозвольте багатьом розробникам змінювати тестовий примірник програми php, не даючи їм корінь (я думаю, вони копіюватимуть файли) --- Я веду команду молодших розробників некомерційних організацій, і мені потрібно дотримуватися цього простого!

EDIT

Налаштування SGA-біта AFAIK не враховується, він впливає лише на новостворені файли --- та базовий робочий процес для цих випадків використання, копіювання ivnolves та інших операцій (які відклеюють gid файлу незмінним)

Відповіді:


9

Списки контролю доступу

Пряма відповідь - списки контролю доступу (ACL) . Так, ви можете знайти контрприклад, але вони на практиці достатньо хороші (на відміну від простої групової записуваності, яка вимагає, щоб користувачі думали про це постійно). Вони вимагають, щоб системний адміністратор (root) визначав групи, якщо ви хочете, щоб файли мали спільний доступ лише з названою групою (root може вибрати делегування, наприклад, приймаючи групи від LDAP, але це вже інша історія).

Користувачам, які беруть участь у програмі, потрібно мати номер 022. Якщо вони створюють непрочитані файли, які не можна прочитати, ця схема не працюватиме. Але якщо вони мають обмежувальний умаск, це, мабуть, тому, що вони все одно не хочуть ділитися файлами.

Увімкнення ACL

Ubuntu за умовчанням не вмикає ACL, тому існує разова вимога адміністратора. Відредагуйте /etc/fstabза допомогою улюбленого редактора та змініть кожну лінію, що відповідає файловій системі, де ви хочете ділитися файлами: додайте aclдо параметрів. (Переконайтеся, що не змінюйте жодного іншого рядка та не використовуйте редактор, який обертає довгі рядки.) Ось приклад рядка з aclдоданою опцією:

UUID=5e1ec7ed-face-dead-beef-c011ec7ab1e5  /  ext4  errors=remount-ro,acl  0 1

Щоб опція набула чинності вперше, використовуйте таку команду, як наступна (для кожної файлової системи):

sudo mount -o remount,acl /

Встановіть у aclпакет інструменти ACL .

Налаштування спільного каталогу

Щоб група спільно використовувала файли mygroup:

setfacl -m group:mygroup:rwx /path/to/shared/root
setfacl -d -m group:mygroup:rwx /path/to/shared/root

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

Якщо у вас немає групи Unix, ви можете додавати користувачів по одному:

setfacl -m user:bob:rwx /path/to/shared/root
setfacl -d -m user:bob:rwx /path/to/shared/root

Контроль версій

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

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


ACL відмінно працював, якби автоматичне успадкування не було порушене cp (і mv?), Яке відкидає (ігнорує) ACL за замовчуванням, встановлене на рівні цільового каталогу.
корисно

2

Просто зробіть це:

mkdir /src/teamA
addgroup teamA
chgrp teamA /src/teamA
chmod g+rws /src/teamA

Тепер усі в teamAгрупі можуть зробити все всередині/src/teamA

Магія - це жорсткий біт (встановити ідентифікатор групи) в каталозі.


AFAIK він не працюватиме, дивіться оновлений пост
jb.

1

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

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

Коротко, ти біжиш

sudo bindfs -o perms=0700,mirror-only=user1:user2:user3 /home/shared /home/shared

зробити доступ / home / shared доступними для користувача1, user2 та user3.

Інструкції

Повні інструкції, включаючи постійне налаштування (щоразу при включенні комп'ютера), див. У розділі Bindfs-SharedDirectoryLocalUsers (документація на Ubuntu ). Я використовую це на власній машині для декількох каталогів, кожен з яких має різні групи спільного використання (одна папка доступна для всіх облікових записів, інша лише для робочих рахунків, інша лише для особистих облікових записів).

З поста:

bindfs - файлова система FUSE для встановлення каталогу в інше місце (точка монтажу) з налаштуваннями дозволу. Це дозволяє вказати право власності та дозволи на файли зсередини точки монтажу.

...

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

Списки контролю доступу (ACL)

Документація примітки:

Якщо ви хочете налаштувати більш розширені дозволи для різних користувачів та / або групи, спробуйте списки контролю доступу .

Дивіться відповідь Гілла для отримання більш детальної інформації.


якщо у вас виникають проблеми з додаванням bindfs на oneiric, ви можете отримати тут створені користувачем пакети bugs.launchpad.net/ubuntu/+source/bindfs/+bug/851600
david.libremone

-3

Ви можете комбінувати рішення шелхоліка з завданням cron, яке оновлює gid для всіх файлів у цій папці кожні 15 секунд або щось подібне.

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