Добавление пользователю прав без логаута

Если «ресурсы» - объекты файловой системы, то можно использовать
Access Control Lists (ACL), если, конечно, ФС их поддерживает.

http://www.opennet.ru/man.shtml?topic=newgrp&category=8&russian=0 А что за ресурсы то? Может есть более простой путь.

Для смены членства в группах необходимы права суперпользователя. Обычный процесс ими не обладает и не может получить права суперпользователя в ходе своей работы (только через exec(), но это будет уже другой процесс).

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

Так автор - админ.
Автору - selinux\apparmor?

Хорошо, сформулирую по другому. Для вызова setgroups() процесс должен работать от имени суперпользователя. Поэтому уже работающий DE не может перейти из одной группы пользователей в другую (не может «перечитать права» как хочет ТС).

Не знаю насчёт apparmor, но политики SeLinux'а, ЕМНИП, грузятся достаточно долго. Если я правильно понял ТС, то он хочет, чтобы на некоторое время у работающего пользователя поялялись определённые права, а потом исчезали. Разве что изначально написать включаемые правила и «рулить» с помощью setsebool.

Да, именно объекты файловой системы. И ACL я применяю. Права на ресурсы назначаются группам, к примеру группа A имеет доступ к ресурсам a1, a2 и a3. Ввели пользователя в группу A и доступ к ресурсам появился, вывели и нет доступа. Можно, конечно, давать права не группе, а пользователю, но тогда надо запоминать к каким именно ресурсам он имеет доступ и при смене группы пробегать по всем и ставить/снимать права. Не хочется так делать.

Начал делать установку прав для конкретных пользователей и возникла проблема. Если при установке прав запомнить имя файла, то к тому моменту, когда права нужно будет модифицировать он может быть переименован и будет печально. Соответственно, надо, наверно, запоминать идентификатор файла и идентификатор устройства (черeз stat, к примеру). Но! Каким образом по этим идентификаторам потом можно будет получить имя файла. Не нашел функции преобразования :(

Сделай fuse-обёртку и проверяй в ней права на каждый чих.

Если пользователю разрешено открыть файл на запись и он его открыл, а потом у него право отняли, должен ли он уметь писать в файл до закрытия? Или запись обрывается? Аналогичный вопрос с чтением, правом выполнения (как для файлов, так и для директорий). Должно ли человека выкидывать из директории? Должны ли прерываться процессы?

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

Если ты имеешь в виду inode, то потом найти файл можно с помощью 'find <точка монтирования> -inum <inode>'
Беда в том, что это может быть как долго, так и очень долго.
Если гарантировано, что ссылка после переименования/перемещения находится в каких-то определенных каталогах, то может быть чуть быстрее, если натравливать find только на них.
Так что, возможно, лучше отслеживать переименования c помощью inotifiwait, например.