Вопросы Теги

getpcaps не работает в Ubuntu 20.04 с Linux 5.11.0 -38 -общий

Не делайте этого или любой версии того, что вы пытаетесь сделать, но вы можете использоватьyes:

$ yes 'password' | sudo -Su USER rm -f FILE

Вместо этого вы должны разрешить USERдоступ к sudo без пароля, изменив/etc/sudoers(использование visudoтам, где доступно ), и добавив этого пользователя в требуемую группу.

Как запустить определенную программу от имени пользователя root без запроса пароля?

0
08.11.2021, 13:57
1 ответ

Не-нулевое значение, на которое вы смотрите в этом файле состояния, — это ограничивающий набор (, который является своего рода верхней границей фактических возможностей ). Ограничивающий набор предназначен для ограничения возможных возможностей процесса. Это отличное от -нулевое значение является значением по умолчанию для системы. Таким образом, это не интересное значение. Это говорит о том, что это все возможности, известные работающей системе. Его значение становится интересным , когда оно отличается от значения по умолчанию.

С различными Cap*записями в этом файле статуса связано много инкрементной истории. Только CapInh, CapPrmи CapEffбыли в начале (~1999? ). Они были введены для реализации проекта спецификации POSIX.1e (, см. внизу этой страницы ссылку на последнюю известную копию указанного проекта). Библиотека libcap, которая предоставляет программу getpcaps, изначально была разработана как реализация пользовательского -пространства API для возможностей, описанных в этой спецификации. Текстовое представление возможностей из этой спецификации включало только эти три флага возможностей .

Согласно спецификации, CapInh, CapPrmи CapEffявляются фактическими возможностями для процесса, и только CapPrmи CapEffна самом деле дают процессу некоторые прямые привилегии.

Позже, CapBndбыл сделан ограничивающий набор -для каждого процесса, из которого процесс может удалять только биты (по модулю контейнера пространства имен пользователя. Недавно исправлены ошибки ). И после этого было добавлено CapAmb. Семантика этих двух векторов заключается в том, что они наивно наследуемы -дочерний элемент наследует точную копию своего родителя во время exec*(). Это сильно отличается от семантики CapPrmи CapEff.

Когда мы рассмотрели эту семантику и наследие (~20 лет )текстового представления для поддержки концепций A и B,мы создали другое текстовое представление для кортежа 3 -:I, A и B :кортежа IAB. Вы можете прочитать об этом на справочной страницеcap_iabили в документации для pam_cap.so. Текстовый формат IAB — это то, что pam_cap.soиспользует для своего синтаксиса конфигурации. B на самом деле представлен как инверсия к CapBnd, чтобы подчеркнуть, что значение по умолчанию — неинтересное нулевое значение. Существует более подробное обсуждение всех этих механизмов, сосредоточенное на наследовании возможностей здесь .

Примеры, которые вы могли бы попробовать (для целей сравнения):

$ getpcaps 1

У этого будет множество возможностей ...=ep. Подробнее о том, как работают все возможности, можно прочитать на веб-сайте libcap. Более поздние версии getpcapsподдерживают параметр командной строки --iab, который, если он находит интересное(не -значение IAB по умолчанию ), добавляет текстовый вывод для процесса с [..IAB..]. В примечаниях к выпуску говорится, что эта поддержка была добавлена ​​в libcap-2.54.

Я не уверен, какую версию libcapвы установили, но на момент написания libcap-2.60является текущей версией. Он знает все о безымянных возможностях, которые вы видите :с номерами 38, 39 и 40. Фактически, версия libcap-2.60capshдаже поддерживает такие вещи, как:

$ capsh --explain=40
cap_checkpoint_restore (40) [/proc/self/status:CapXXX: 0x0000010000000000]

    Allows a process to perform checkpoint
    and restore operations. Also permits
    explicit PID control via clone3() and
    also writing to ns_last_pid.
0
15.11.2021, 04:35

Теги

Похожие вопросы