Обмен файлами между пользователями без общей группы.

Если есть права рута на этом сервере то можно включить POSIX ACL на этих фс и раздавать права как душе угодно.

В приведённом выше методе лично я особых уязвимостей не вижу если «пароль» будет длинный и каталог будет существовать недолгое время.

Правда наверное брутфорс имени каталога ограничить никак не получится.

Нет, прав рута к сожалению нету. Брутфорс будет ограничен как раз длинной имени каталога и временем жизни. Максимальная длина имени сейчас в линукс системах немалая.

Сомнения - нельзя ли будет как-то системными способами получить имя каталога? Например через какие-нить логи или запросив как-нить список открытых файл-дескрипторов или ещё что-нить такое?

а чем не устраивает GnuPG?

Кстати да, почему нельзя просто тупо зашифровать большим паролем и выложить на всеобщий доступ?

> Например через какие-нить логи
В зависимости от того, какие действия будут производится в/над «секретным» каталогом, при обычном cp - не должно по идее

запросив как-нить список открытых файл-дескрипторов

Доступны только открытые дескрипторы текущего пользователя.

Старый сервис locate может выдавать лишнюю инфу, но он по-моему сейчас уже нигде не стоит (заменён на другие реализации locate, типо slocate и mlocate)

Вариант с gpg, описанный выше в любом случае надёжнее =)

общедоступная папка + gpg

К сожалению вариант с GPG не подходит, в силу следующих причин:

1. Файлы могут быть большими и очень большими, нормальные порядки размеров файлов - гигабайты и терабайты. А могут быть и не очень большими, но в количестве несколько сот тысяч штук.

2. ВАЖНЕЕ - файлы второй пользователь должен получить в не зашифрованном виде, поскольку использовать их сразу при получении будет не сам пользователь, а софт, запускаемый от имени этого пользователя. И этот софт является немодифицируемым.

При этом пользователи на сервере не имеют общих групп и иметь не могут в принципе

Файлы могут быть большими и очень большими, нормальные порядки размеров файлов - гигабайты и терабайты.

Не может такого быть, чтоб нельзя было сделать группу «special», членами которой сделать этих двух пользователей, чтоб только они [и root (: ] вдвоем могли использовать на её на чтение\запись, тем более если речь идет о таких объемах.

если какой другой пользователь входит в группу disk, то он сможет через debugfs слить себе все

хм, даже рутовский каталог можно так прочитать - непойму зачем нужна группа disk ?

для записи на дисковые устройства, видимо.

похоже для чтения из устройства (согласно правам на /dev/sdaX)

это от дистрибутива зависит, видимо. Смотря как гайки закрутят

brw-rw---- 1 root disk 8, 0 Мар 25 2010 /dev/sda

И тем не менее, общую группу сделать нельзя. Такова политика работы на данном сервере. И эта политика имеет обоснования и является неизменной.

Более того, нельзя запользовать ACL (setfacl) потому, что на сервере его нет. Точнее так: на сервер подмонтирован раздел для работы с большими объёмами данных. Поскольку обмен у пользователей именно такими данными, то они должны использовать именно этот раздел. Но на нём файловая система Lustre и ACL там не настроен. Админы не уверены, что его вообще можно на Lustre настроить.

получается, что группа disk очень «приближена» к правам root, хотя об этом нигде особо не упоминается

rsync + rsyncd
с авторизацией.

если ты имеешь право писать на блочное устройство, а на нём есть примонтированная без nosuid файловая система — то ты можешь туда положить bash и поставить ему SUID root...

И тем не менее, общую группу сделать нельзя.

Чушь

Такова политика работы на данном сервере. И эта политика имеет обоснования и является неизменной.

является неизменной

чушь

Если ставить себя в такие ограничительные рамки, то не обойтись без велокостылей (то, что вы предложили - вроде как рабочий вариант)

$ cat test
mkdir a
mkdir a/verylongdirname
touch a/verylongdirname/scrap

chmod 111 a
ls a
ls a/*

$ sh ./test
ls: невозможно открыть каталог a: Отказано в доступе
ls: невозможно получить доступ к a/*: Нет такого файла или каталога

sudo sh ./test
verylongdirname
scrap

От корешка всё-равно не скроешься!

на то он и суперпользователь. А вот в винде приходилось сталкиваться с маразмами системы ограничения прав.

Ну зачем так категорично? На сервере ведётся биллинг, за пользование вычислительными ресурсами. Пользователь входит всегда в какой-то проект и может использовать ресурсы сервера. Привязан пользователь к проекту через свою группу. И когда используются вычислительные ресурсы, то деньги идут с группы и соответствующего проекта.

Если пользователь входит в несколько проектов, то будет входить в несколько групп. Биллинг идёт по главной группе, которую пользователь может сам изменить. Групп, за которыми не стоят проекты быть не может. Иначе пользователь переключившись на неё будет бесплатно пользоваться вычислительными ресурсами.

Больше одной группы на проект быть тоже не может - особенности биллинга.

Всвязи с вышеизложенным нельзя создать группу на двух пользователей только для обмена данными.

А не лучше-ли сделать наоборот: файл, куда писать может любой, а читать — только владелец? Это сделает утечку данных менее вероятной… Можно md5 проверять, чтобы убедиться, что написал именно тот, кто нужно…

Больше одной группы на проект быть тоже не может - особенности биллинга.

Привязан пользователь к проекту через свою группу.

Это же нелогично! Тогда надо было по логину привязывать.

Логика в том, что деньги платятся не со счёта пользователя, а со счёта проекта. А в проекте много участников, соответственно они все объединяются в группу и деньги снимаются с группы, то бишь с проекта.

Групп, за которыми не стоят проекты быть не может.

а как же быть с системными группами?

Конечно есть такие группы, но обычные пользователи, входящие в проекты, не входят в такие системные группы.

Почему бы не добавить еще одну такую «системную» группу, и сделать нужных пользователей их членами. Основная (эффективная) группа у них не поменяется, зато они смогут делать chown :somegroup /path/to/file и,таким образом, определять права доступа для другого пользователя, входящего в эту группу.

Потому что пользователь может сам сменить основную группу на эту добавленную. Тогда биллинг будет считать на эту группу, а она реально не имеет под собой проекта и соответственно денег.

пользователь может сам сменить основную группу на эту добавленную.

а как это реализовано?

Через обычную команду newgrp.

Пароли на группы могут спасти ситуацию? Допустим я имею uid=azure, gid=azure и состою в группе secure, на которую установлен пароль, которого я не знаю. Как мне кажется, это позволит мне установить доступ для группы secure но не позволит мне изменить gid на secure т.к. я не знаю пароля группы.

изменить gid на secure вы можете всегда, пароль тут не используется. Если на группу задан пароль, то пользователь, не состоящий в группе может сам к ней присоединиться, через ту же команду newgrp, если знает пароль. Если пароль не установлен, то сам пользователь к группе присоединиться не сможет.

Есть ещё один варинант. Создаём именованный канал помощью mkfifo , после этого убеждаемся что другой пользователь зделал cat fifo > tofile и cделал это первым . После чего делаем cat somefile > fifo . Правда как убедится что никто не зделал этого раньше это уже сам придумай.