Як дозволити користувачам передавати файли іншим користувачам на Linux


10

У нас є середовище з декількох тисяч користувачів, які працюють із додатками для приблизно 40 кластерів, розміром від 20 обчислювальних вузлів до 98 000 обчислювальних вузлів. Користувачі цих систем генерують масивні файли (іноді> 1PB), контрольовані традиційними правами unix (ACL, як правило, недоступні або практичні через спеціалізовану природу файлової системи).

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

> give username-to-give-to filename-to-give ...

Потім користувач, що приймає, може використовувати команду під назвою "взяти" (частина програми передачі) для отримання файлу:

> take filename-to-receive

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

Ця програма існує вже багато років, і ми хотіли б переглянути речі з точки зору безпеки та функціоналу.

Наш поточний план дій полягає в тому, щоб усунути біт гнилі в нашому поточному впровадженні "дай" і упакувати його як додаток з відкритим кодом, перш ніж ми перевтілимо його у виробництво.

Чи є у когось інший метод, який вони використовують для передачі надзвичайно великих файлів між користувачами, коли доступні лише традиційні дозволи Unix?


1
Чи є якась причина, чому ви не можете просто створити спільний каталог, де всі користувачі мають доступ?
Zoredache

1
Якщо є каталог із спільним доступом, користувачі без дозволу матимуть доступ до файлів під час їх спільного доступу. У цьому середовищі іноді імена файлів також чутливі. Тож, на жаль, спільний каталог не є варіантом. За допомогою спільного каталогу також існує можливість третього користувача підробляти файл.
Джон Брінгхерст

Не буде достатньо, щоб робота з Cron копіювала самі файли? Приклад: користувач foo хоче надати рядок файлу щеняти користувача. тому він створює спеціалізований каталог, який сканується завданням cron з файлом "control", що містить отримання імені користувача. Завдання Cron прочитають цей файл "керування", якщо користувач в порядку, у каталозі призначення є місце в порядку, копія. Ви все ще можете створити обгортку для "дати", щоб просто створити файл "управління", щоб мати історичну сумісність. Немає необхідності в suid-root, ви можете скопіювати цей файл під не-root користувача, а потім sudo для зміни власності.
джиріб

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

@JiriXichtkniha Мені подобається ідея керуючого файлу та завдання cron. Однак файли занадто великі для їх копіювання.
Джон Брінгхерст

Відповіді:


1

Якщо випромінювач дійсно готовий надати файл, ви можете використовувати двійковий файл SUID, який переміщує файл у каталог, який можна записати всім і має клейкий біт (як /tmp), а потім змінює право власності на нового власника. chown(3)вже піклується про видалення set-user-IDта set-group-IDшматочки для вас. Таким чином новий власник може робити з файлом все, що хоче, включаючи його переміщення.

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

Електронна пошта зробила б свою справу. Більш реальним рішенням Unixy було б /etc/profileперелік ваших щойно доставлених файлів. Доданий бонус, якщо ви пропонуєте цю функцію за допомогою pam_echo( наприклад, з file=/tmp/deliveries/%u, див. pam_echo(8)). Як і у випадку, що стосується PAM, ви хочете спочатку перевірити, чи всі ваші реалізації пропонують такий модуль.


0

Ви можете використовувати систему із спільним каталогом (можливо, без виконання perms.), Де речі для певного користувача архівуються з певною структурою імен файлів ( to-$username_from-$username.tarнаприклад). Give робить файл і chownsйого цільовому користувачеві; взяти витягує файл і видаляє його.

Якщо ви хочете зробити це як власне переміщення (IE, змінити розташування файлу та дозволи; відсутність копіювання через гігантський розмір файлу), ви, можливо, зможете піти з переходу до спільного каталогу з -x perms (тому ніхто не може список файлів там) і тим самим chownметодом. mv, chown/ mv.


0

Як говорить xryl669, ви можете використовувати каталог для фактичного обміну файлами. Це повинно виглядати так:

$ ls -ld shared
drwxrws--- 2 root usergroup 4096 somedate shared
$ ls -l shared
drwx-wx--- 2 user1 usergroup 4096 somedate user1
drwx-wx--- 2 user2 usergroup 4096 somedate user2
drwx-wx--- 2 user3 usergroup 4096 somedate user3
drwx-wx--- 2 user4 usergroup 4096 somedate user4

Команда give стає

#!/bin/sh
#Use a random suffix to prevent guessing
RANDOM=$(dd if=/dev/urandom count=4 2> /dev/null | sha512sum | cut -d' ' -f1)
NEWNAME=/path/to/shared/$2/$1$RANDOM
#Move the file
mv $1 $NEWNAME
#Make it readable
chmod 440 $NEWNAME

Команда take виглядає приблизно так:

$ cd /path/to/shared/user
$ ls
...
$ mv somefile ~

0

Я б запропонував переписати додаток, щоб дійсно імітувати "подати" та "взяти", а краще "натиснути" та "витягнути" його із захищеного каталогу. Ваш каталог може бути доступний лише для програми "push / pull", яка обробляє переміщення файлу. Крім того, ваш додаток / сценарій може створити випадковий тимчасовий каталог з дозволами, встановленими лише для відправника та одержувача.

Хочете мати більше безпеки? Ви можете PGP зашифрувати / підписати файл (за допомогою відкритого ключа приймача).

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


0

Це, мабуть, не для вас корисно, але для довідкового cp --reflink source target робить тонкі копії файлів за допомогою копіювання при записі .

Це означає, що ви можете скопіювати файл прямо, а фактично скопійовані лише змінені блоки. На відміну від жорсткого посилання, новий файл має власні inode та метадані, тобто ви можете надати копію цього файлу новому користувачеві, використовуючи стандартні дані про chown.

Наскільки мені відомо, це функція, яка доступна лише в OCFS2 та btrfs. Я думаю, що це вирішує вашу проблему, але, враховуючи, що її наявність не є широко поширеною, це, мабуть, не буде корисним.

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