Зачем нужен sudo?

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

Ты перепутал. Он, в отличие от firkax, вроде адекватный

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

Ну да я считаю что юзеру нефиг делать с критичными сервисами.
Свои пусть запускает хоть с & и делает с ними что хочет. И то еще как посмотреть.

к сожалению практика сильно отличается от всех тэорий :)

Твоя практика дефективна, смирись с этим и перестань её тут всем впаривать в качестве образца.

океюшки сударыня :) коль дефективна, дык не вопрос
только вот расскажи как с помощью su дозволить пользователю запуск только одной команды, к примеру, перезапуск системного демона systemctl restart aaa.service и более никаких действий с повышением прав.
в sudo это делается элементарно. а каково будет твое решение данной проблемы.

Это нельзя и не надо делать с помощью su. su это утилита для перелогина в рута или другого юзера, а не для ребута сервисов.

С помощью sudo - тоже не надо. И в очередной раз повторю, что выдавать доступ опираясь на текстовый анализ команды (это именно то, чего делает дефективное sudo) - это фу. Не надо выдавать доступ к строке «systemctl restart aaa.service», надо выдавать доступ к действию «перезапустить сервис aaa». А юзер, обращающийся за этим перезапуском, даже знать не должен, что там внутри - systemctl, init-скрипт, отправка демону сигнала или ещё чего. Команда может выглядеть как-то так: restart-aaa, и представлять из себя например setuid-root бинарник с правами 4710 и группой allow-restart-aaa, делающий нужное действие. А того юзера соответственно надо в эту группу добавить.

Иными словами: юзер не должен «запускать что-то там с повышенными правами», он должен «обращаться к системному сервису».

Не надо выдавать доступ к строке «systemctl restart aaa.service»

Иными словами: юзер не должен «запускать что-то там с повышенными правами», он должен «обращаться к системному сервису».

Кто сказал?

Команда может выглядеть как-то так: restart-aaa, и представлять из себя например setuid-root бинарник с правами 4710 и группой allow-restart-aaa, делающий нужное действие. А того юзера соответственно надо в эту группу добавить.

На каждую команду писать по суидному бинарю?

Кто сказал?

Ну ты меня цитируешь а потом спрашиваешь кто сказал. Очевидно это моя цитата. Считаю что такой подход способствует большему порядку в целом. Рутовые команды они для администратора, пользователь не должен забивать себе ими голову вообще. Ну и как бонус, не будет пытаться подсунуть им какие-то неожиданные параметры.

На каждую команду писать по суидному бинарю?

Что за «каждая команда»? Он хочет (правда, непонятно зачем) дать одному юзеру-неадмину возможность перезапуска одного сервиса через шелл.

Приведи пример. Желательно с описанием зачем это вообще нужно.

Очевидно это моя цитата.

Так ты совсем не авторитет, сорри. Ты такого тут писал, что волосы шевелились. И что mysql только на локалхостах стоит в основном, и что innodb не нужен, только myisam, что апач не нужен, докер не нужен, в общем, сильно закостенел уже.

Он хочет (правда, непонятно зачем) дать одному юзеру-неадмину возможность перезапуска одного сервиса через шелл.

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

У systemd специально для этого есть polkit, не надо ни su, ни sudo.

systemd не везде есть и работает, но посмотреть-изучить надо

Так ты совсем не авторитет, сорри

Я в курсе что для тебя это так. Но транслировать чьи-то мнения я в любом случае не собираюсь, только своё собственное.

Но я не сторонник подхода «наворотить нереальной безопасности и в идеале совсем отбрехаться от задачи»

Я то тут при чём?

и писать велосипеды при наличии промышленного решения.

Если так называемое промышленное решение не выдерживает никакой критики то пользоваться им не надо.

Так а пример то будет? Про «на каждую команду». Ты, как я понимаю, считаешь, что где-то будет очень много таких «команд» и из-за этого придётся делать очень много суидных бинарей и это плохо.

Если так называемое промышленное решение не выдерживает никакой критики то пользоваться им не надо.

Это всего-лишь твои слова, доверху полные когнитивных искажений.

Я то тут при чём?

Так ты, судя по всему, сторонник :)

Так а пример то будет?

Скажем так, есть девелоперские сервера, где нужно выполнять по 2-3 команды на девелопера с привилегиями суперпользователя. Девелоперов много. sudo - промышленное решение, настраивается хорошо, за безопасностью следят.

Ты же предлагаешь навелосипедить суидных бинарей.

Это всего-лишь твои слова, доверху полные когнитивных искажений.

Тут всё чьи-то слова. И, повторюсь, я не считаю чьи-то чужие слова лучше моих. Надо не на авторство смотреть а не содержание.

Что за команды то, пример? А то опять общие слова. Допустим, четырёх девелоперов с их разными командами по 2-3 на каждого придумаешь?

И, повторюсь, я не считаю чьи-то чужие слова лучше моих.

Зато я считаю.

Надо не на авторство смотреть а не содержание.

Естественно.

придумаешь

А, понятно, лесом уходишь.

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

да я не против альтернатив. больше вариантов - больше выбора.
представь команду альтернативную простому примеру представленному раньше sudo systemctl restart aaa.service

firkax прикладной пример: веб-макаке нужен доступ на перезагрузку веб-сервера, запущенного в системном systemd.
звонить и каждый раз просить сисадмина ?? ни один сисадмин не выдержит, да и не интересны ему такие мелочи.

dместо самодельного setuid-бинарника restart-aaa это извините тоже бааальшая дырка в безопасности, простенький скрипт содержащий sudo systemctl estart aaa.service.
вместо самописного костыля проверенный десятилетиями код sudo.

принцип «KISS - сделай это проще, тупица !!» в своей красе.

представь команду альтернативную простому примеру представленному раньше sudo systemctl restart aaa.service

system restart aaa.service

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

Если тебе надо запустить команду от другого пользователя, не являясь рутом, тебе нужен sudo / doas / run0. Ну или ssh root@localhost.

Речь о том, что в принципе такая задача это задача из разряда «как организовать пронос сумок мимо охраны, не показывая им пропуск». Понятно, что это самый простой способ решить поставленную задачу, но не обязательно правильный с точки зрения безопасности и прочего. Правильный способ это подход systemd, где имеется запущенный от рута процесс, принимающий запросы от пользователя, авторизующий эти запросы и выполняющий. А может и без рута можно обойтись, рут на самом деле нужен для очень малого числа задач.

С помощью sudo - тоже не надо. И в очередной раз повторю, что выдавать доступ опираясь на текстовый анализ команды (это именно то, чего делает дефективное sudo) - это фу.

а чем занимается su тоже делает текстовый анализ /etc/passwd и прочих текстовых файлов.

если зреть в корень то без разницы :), просто связь с пользователем разная: у sudo stdout/stdin, а у системд так понимаю файловый сокет (??), ну и ssh с ssh-соединением.
процессы исполнители работают от root.
да, можно исполнителей запустить и не под root.

sudo это экзешник с suid. Это очень большая ответственность - держать такой экзешник в системе. Многие баги в sudo превращаются в таких условиях в уязвимость. Если такой экзешник можно не держать в системе, лучше не держать.

При этом sudo сама по себе очень сложная программа и грузит много разных библиотек, т.е. пассаж про баги распространяется и на них.

ssh и systemd из системы убрать не получится, поэтому это обсуждать смысла нет.

su тоже вызывает неограниченное количество библиотек из PAM, поэтому в системе PAM лучше не держать.

ssh и systemd из системы убрать не получится, поэтому это обсуждать смысла нет.

В Docker контейнерах systemd и ssh нету.

su подключается к pam, а дальше происходит непонятно что, скоро /etc/{passwd,shadow} будет заменен на passwdctl, Linux Is No UniX

sudo это экзешник с suid.

Что такое «экзешник» ?

su подключается к pam

А если pam отсутствует то работать не будет?

Тогда не запустится вовсе.

executable file

программа иными словами

su подключается к pam

А если pam отсутствует то работать не будет?

Тогда не запустится вовсе.

Очень смешно. И как же оно у меня столько лет (18 точно) работало? Наверное чудеса.

#!/bin/sh
echo "я не программа что ли?"

Это программа?
А:

#include <stdio.h>
int main(int argc, char * argv[])
{
  printf("Hello LOR\n");
  return 0;
} 

Удивлю, есть разные реализации, из какого пакета твоя? Обычно используют из util-linux, я говорил про нее.

Не очень понимаю, к чему этот вопрос? Если про то, что в линуксе не работает suid бит на скриптах, я в курсе, но какое это отношение имеет к дискуссии - не понимаю.

скомпилированый бинарник, теперь только упакованый в elf формат, раньше были и не упакованые

в скрипт можно упаковать /usr/bin/apt update;/usr/bin/apt -y upgrade и через sudo выполнять такое, а с suid придётся писать и компилировать бинарник.

если бы polkit еще умел брать правила из ldap. пару лет назад рассматривали его как замену sudo, но без ldap грустно

Удивлю, есть разные реализации

Та шо ви говорите...

из какого пакета твоя?

shadow

Обычно используют из util-linux

«Обычно» это где? На «Обычной» планете? Вот например у меня в util-linux её нет, я что-то делаю не так?

Я вам задал вроде бы простой вопрос «Что такое «экзешник» ?» Вы ответили «программа иными словами». Вот теперь я пытаюсь понять что такое «программа» в вашем понимании.

скомпилированый бинарник, теперь только упакованый в elf формат, раньше были и не упакованые

Тоесть например libz.so.1.2.8 это «экзешник» ?

библиотека .so это elf формат так что биарник, я вот только не знаю на неё действует ли suid бит?

работу бита suid на скриптах я так предполагаю можно включить патчем файла binfmt_script.c который определяет исполнение файла начинающегося с #!
но почему-то такая возможность исключена. интересно почему, дыра в безопасности ?? :)

также там определены какие файлы являются исполняемыми для ядра линукса.

не знал что такое можно.

https://security.stackexchange.com/questions/194166/why-is-suid-disabled-for-shell-scripts-but-not-for-binaries

Вот тут объясняют, почему.

Программа, это то, что я запускаю в терминале, за вычетом скриптов. Скомпилированные файлы. То, что обычно валяется в /usr/bin и тд. То, на что можно повешать suid бит и он будет работать. Вероятно это ELF файл, который запускается через ld-linux.so, но это не точно, я никогда досконально не исследовал механизм запуска бинарников в линуксе, чтобы давать железобетонные определения. В контексте suid битов это то, что ядро запускает под привилегиями, отличными от привилегий родительского процесса, в частности под привилегиями рута.

https://unix.stackexchange.com/questions/511790/what-types-of-executable-files-exist-on-linux
только на данный момент a.out уже выброшен.

Вот у вас уже начали появляться сомнения. Хотя конечно странно, что сомнения.

Т.е. в принципе все, что в конечном итоге ведром будет обработано, можно считать программой?

мы много чего можем считать :) это наше личное мнение.
главное как на это обрабатывает операционка.