Ограничение доступа к определённым приложениям.

sudo?

>В целях повышения сохранности данных

как виртуальгроб может повредить данные?

Можно просто проставить права на исполняемые файлы. Чем такой вариант не нравится?

Хочу разные пароли для разных программ. Создавать на каждую своего пользователя - костыль :)

И да, это в целях сохранности данных от чужих ручек.

g Мандатная модель доступа

А морда где?

>А морда где?
в виндус сервер 2010

так а чем sudo не угодил?

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

Урезать права я могу. Полистать доки по GrSec или SELinux - тоже. Можно и доки по TOMOYO, AppArmor или LSM почитать))) Но морды от этого не появится. Да и в ядро для этого лезть не обязательно.

Вполне можно ограничиться существующими механизмами аутенификации, полагаю. Нужно лишь немного переписать часть кед или нужные приложения.

man pam
/etc/pam.d
/etc/pam.conf

Быстрее через su (gksu, kdesu), для нужных программ.

man очки

>Быстрее через su (gksu, kdesu), для нужных программ.

Оно умеет разные пароли?

ведь sudo умеет задавать для каждого пользователя на каждое приложение отдельный пароль

повесить на кнопку запуска «выполнить в терминале sudo virtualbox» и все

ну сделай пару юзеров, жрать не просят

Ну ведь написал что не хочу такой костыль)

А вообще, лучше бы вы рассказали почему такая возможность не нужна)

Пишем скрипт, который
- перемещает заданный бинарник в спец. каталог, не указанный в $PATH
- ложит на его место свежесгенерированный скриптик-заглушку, который вызывает ещё один скрипт, управляющий аутентификацией

При попытке вызова обработанной ним программы:
- запускается скрипт-заглушка
- вызывается скрипт-аутентификатор
- аутентификатор запрашивает пароль (детали не важны)
- если успешно, запускаем программу из того скрытого каталога

То что ты хочешь не меньший костыль.

Это система аутенификации. Они ничем не будет отличаться от модуля pam, проверяющего пароль где угодно и как угодно так, что кеды об этом не задумываются.

Ненадёжно, на первый взгляд. Можно узнать где лежит бинарник.

исполняемый бит на группу, на группе пароль
пусть пользуются sg

Ну это ж только набросок, концепт, так сказать.

Вот ещё одна. Не хочу на каждую программу нового юзера. И группу тоже. Потому что это костыль.

Если ещё завести отдельный аккаунт для аутентификатора, содержимое скрытого каталога сделать видимым только этому аккаунту, бинарники не просто перемещать, а ещё и переименовывать случайным UUID'ом, а таблицу сопоставлений оригинальных имён и UUID'ов хранить в шифрованной БД, то добраться откуда ноги растут сможет только обладатель рутовых прав, да и то не сразу :-)

А тут выбор невелик. Либо fast&dirty костыль из существующих механизмов, либо писать все с нуля самому как надо.

А смысла данной технологии я так и не понял. Опиши юзкейс.

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

> Такое вполне можно предложить KDE'шникам.

Тонко. Молодец! :)

{vl}[vl@~]$ ls -l /usr/bin/gedit
-rwxr-xr-x 1 root root 663280 Ноя 8 20:21 /usr/bin/gedit
{vl}[vl@~]$ su -
Пароль:
vl ~ # groupadd geditors
vl ~ # gpasswd geditors
Изменение пароля для группы geditors
Новый пароль:
Повторите новый пароль:
vl ~ # chgrp geditors /usr/bin/gedit
vl ~ # chmod o-x /usr/bin/gedi
gedi gedit
vl ~ # chmod o-x /usr/bin/gedit
vl ~ # ls -l /usr/bin/gedit
-rwxr-xr-- 1 root geditors 663280 Ноя 8 20:21 /usr/bin/gedit
vl ~ # exit
logout
{vl}[vl@~]$ gedit
-bash: /usr/bin/gedit: Отказано в доступе
{vl}[vl@~]$ newgrp geditors
Пароль:
vl@vl ~ $ gedit
vl@vl ~ $