У нас есть среда, в которой несколько тысяч пользователей запускают приложения примерно на 40 кластерах размером от 20 вычислительных узлов до 98 000 вычислительных узлов. Пользователи этих систем генерируют массивные файлы (иногда> 1 ПБ), управляемые традиционными разрешениями unix (ACL обычно недоступны или нецелесообразны из-за специализированного характера файловой системы).
В настоящее время у нас есть программа под названием «give», которая представляет собой программу suid-root, которая позволяет пользователю «передавать» файл другому пользователю, когда права группы недостаточны. Итак, пользователь должен ввести что-то вроде следующего, чтобы передать файл другому пользователю:
> give username-to-give-to filename-to-give ...
Затем принимающий пользователь может использовать команду под названием «take» (часть программы give) для получения файла:
> take filename-to-receive
Затем права доступа к файлу передаются принимающему пользователю.
Эта программа существует уже много лет, и мы хотели бы пересмотреть ее с точки зрения безопасности и функциональности.
Наш текущий план действий состоит в том, чтобы удалить гниль в нашей текущей реализации «give» и упаковать его как приложение с открытым исходным кодом перед повторным развертыванием в производственной среде.
Есть ли у кого-нибудь другой метод, который они используют для передачи чрезвычайно больших файлов между пользователями, когда доступны только традиционные разрешения unix?
Если эмиттер действительно хочет отдать файл, вы можете использовать двоичный файл SUID, который перемещает файл в каталог, доступный для записи всем, и имеет липкий бит (например, /tmp), затем переходит к новому владельцу. chown(3) уже позаботится об удалении set-user-ID и set-group-ID бит для вас. Таким образом, новый владелец может делать с файлом все, что хочет, в том числе перемещать его.
Этот каталог, доступный для записи всем, может принадлежать домашнему каталогу пользователя, если вы хотите использовать несколько файловых систем для домашних каталогов и хотите убедиться, что вы не пересекаете границы файловой системы, поскольку производительность сразу же будет ужасной. В этом случае вы, вероятно, захотите убедиться, что получатель знает, когда предлагается новый файл.
Электронная почта сделает свое дело. Более Unixy-решение было бы /etc/profile в котором перечислены ваши недавно доставленные файлы. Добавлен бонус, если вы предлагаете эту функцию с pam_echo (например с участием file=/tmp/deliveries/%u, видеть pam_echo(8)). Как и во всем, что связано с PAM, вам нужно сначала проверить, все ли ваши реализации предлагают такой модуль.
Как говорит 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 ~
Вы можете использовать систему с общим каталогом (возможно, без разрешения на выполнение), где вещи для данного пользователя архивируются с определенной структурой имени файла (to-$username_from-$username.tar, например). Give делает файл и chowns это целевому пользователю; take извлекает файл и удаляет его.
Если вы хотите сделать это как фактическое перемещение (IE, изменение местоположения файла и разрешений; без копирования из-за гигантского размера файла), вы можете избежать перехода в общий каталог с помощью -x perms (чтобы никто не мог список файлов там), и то же самое chown метод. mv, chown / mv.
Я бы посоветовал переписать приложение, чтобы оно действительно имитировало «дать» и «взять», а скорее «протолкнуть» и «вытащить» его из защищенного каталога. Ваш каталог может быть доступен только для приложения push / pull, которое обрабатывает перемещение файлов. В качестве альтернативы ваше приложение / сценарий может создать случайный временный каталог с разрешениями, установленными только для отправителя и получателя.
Хотите больше безопасности? Вы можете PGP зашифровать / подписать файл (используя открытый ключ получателя).
Что касается переделки с «точки зрения безопасности и функциональности», я настоятельно рекомендую не для создания программ SUID. Если вы не откажетесь от привилегий должным образом, вы получите практически доступ к любому файлу в системе. Если ваша программа содержит ошибки (переполнение буфера и т. Д.) - это можно использовать для получения root-доступа в вашей системе.
Это, вероятно, бесполезно для вас, но для справки cp --reflink исходная цель делает тонкие копии файлов с помощью копирования при записи.
Это означает, что вы можете напрямую скопировать файл, и на самом деле будут скопированы только измененные блоки. В отличие от жесткой ссылки, новый файл имеет собственный индексный дескриптор и метаданные, что означает, что вы можете затем предоставить копию файла новому пользователю, используя стандартные файлы chown.
Насколько мне известно, эта функция в настоящее время доступна только в OCFS2 и btrfs. Я предполагаю, что это решит вашу проблему, но, поскольку доступность этого не является широко распространенной, вероятно, не будет полезной.