Полномочие для приложения Linux
[
- ]
[
- ][
]В Arch программы устанавливают значения по умолчанию на [
][]/usr/lib[]. Там не следует вручную (почти никогда) возиться; уж точно не с []systemd[]. []systemd[] неспроста обеспечивает переопределение единиц по умолчанию (см. раздел [] "Путь загрузки единиц"[]).[ ]
[ - ][
]Частично это проблема безопасности. Таймаут проверяется на небрежность (например, вы вводите весь пароль, но забываете нажать клавишу enter и отвлекаетесь на что-то). Вы должны знать, что отключение - не самое безопасное решение здесь.[
][ ]
[ - ][
]Когда вы редактируете или переопределяете устройство, вам нужно запустить [
][]systemctl daemon-reload[], чтобы systemd полностью распознал изменение. После создания нового модуля в []/etc/systemd/[] необходимо []daemon-reload[], а затем []отключить [] модуль по умолчанию и []включить [] ваш новый модуль. После этого перезагрузка должна дать желаемый результат. ([]Примечание[]: Однако я не рекомендую этого делать; см. пункт 2.)[ ]
[
]
Индивидуальные привилегии Linux называются "возможностями". Полное описание возможностей, вероятно, слишком много, но в качестве альтернативы двум упомянутым вами опциям, вы можете установить файловые возможности, которые дают непривилегированным пользователям административные права:
[root@localhost]/home# setcap cap_chown+ep /bin/chown
[root@localhost]/home# sudo -iu testUser
[testUser@localhost ~]$ ll /etc/rc.local
-rwxr--r--. 1 root root 0 Jan 27 22:29 /etc/rc.local
[testUser@localhost ~]$ chown testUser /etc/rc.local
[testUser@localhost ~]$ ll /etc/rc.local
-rwxr--r--. 1 testUser root 0 Jan 27 22:29 /etc/rc.local
[testUser@localhost ~]$
Как вы можете видеть выше, любой, кто выполнит chown на этой системе, будет иметь необходимые для этого привилегии ("CAP_CHOWN") из-за команды setcap, которую я запустил. Вы можете стать немного более избирательным, изменив его с +ep на +ei и предоставив привилегии только определенным пользователям при входе в систему, используя pam_cap.so
Следует отметить, что вышеприведенная chown не запускается от имени root, она запускается от имени моего в противном случае непривилегированного пользователя. Если пользователь запускает что-либо кроме этой программы, он не будет иметь этой привилегии, а если исполняемый файл будет изменен, то все возможности, связанные с файлами, будут очищены.
Без явного присваивания прав программа или сценарий будут выполняться как вызывающий абонент.
Setuid будет выполнять программу с правами пользователя владельца файла. Setgid будет запускать программу с групповыми правами файловой группы. Ни один из них не будет работать непосредственно в качестве скрипта.
Для запуска программы (или скрипта) с правами, которые вы определяете в файле конфигурации sudo, можно использовать утилиту, например sudo.
Я считаю, что подсистемы безопасности, такие как SELinux, ограничивают доступ, а не предоставляют его.
Я не знаю, можно ли использовать ACL для предоставления привилегий во время выполнения. Мне никогда не приходилось расследовать.