у кого как... я в основном удаленно подключаюсь к виртуалкам в облаке и все они как правило живут не долго на одном физическом сервере. для меня atch это инструмент, который, как молоток без которого иногда не обойтись, но постоянно он не нужен 😂
конечно у каждого пользователя в системе есть свои сессии и логи, которые хранятся а ~/.cache/atch/ но если работаешь в команде и нужна помощь коллеги, то он может зайти под тем же пользователем и приатачиться к твоей сессии.
у вас отличное внимание! 👍 но я исправлять не буду, потому что в этом примере это не принципиально важно. даже с маской 4755 ничего посторонний пользователь сделать не сможет. он должен быть в группе suex по-любому
suex/sush были написаны из необходимости для конкретного проекта и существующих процессов в действующей инфраструктуре потому что все имеющиеся решения это не совсем то "пальто", которое нужно на сегодняшний день для решения простых задач, а не ради каких-то "звезд".
проект лежит на гитхабе только потому что так удобнее.
В этом то и дело, уважаемый пользователь. Sudo не делает ничего особенного. Всё уже встроено в ядро, Sudo только обвешивает всё различными правилами через кофниг sudoers, который в наше время никому не нужен ни в облаке, ни в контейнерах.
В Unix/Linux есть специальный бит прав setuid/setgid, его называют спец-бит на исполнение.Если он установлен у исполняемого файла, то программа запускается с effective UID/GID владельца файла, а не пользователя, который её запустил. Например, setuid-root позволяет обычному пользователю выполнить программу с правами root (только в рамках этого процесса), как это делает passwd.
у каждого свои задачи и свои требования к агентам. моё решение сделано для того, что мне нужно использовать каждый день, к примеру, ковыряясь в коде, написанном не мной за многие годы существования проекта.
у кого как... я в основном удаленно подключаюсь к виртуалкам в облаке и все они как правило живут не долго на одном физическом сервере. для меня atch это инструмент, который, как молоток без которого иногда не обойтись, но постоянно он не нужен 😂
было бы неплохо! но у меня на это времени нет увы 😎
да, видел недавно zellij, прикольная вещь, но слишком много наворотов для всех моих юскейсов
конечно у каждого пользователя в системе есть свои сессии и логи, которые хранятся а
~/.cache/atch/но если работаешь в команде и нужна помощь коллеги, то он может зайти под тем же пользователем и приатачиться к твоей сессии.
в этом примере если в Dockerfile поставить
USER appпередENTRYPOINT, тогда в скрипте всё равно нужны права рута дляchown...да, вы правы, но в сложных пайплайнах в CI/CD есть много нюансов.
CI/CD не всегда выполняется в контейнере, часто используются bash скрипты c динамической логикой и гейтами.
не стоит преуменьшать сферу применения до одного Dockerfile.
у меня лично десятки юскейсов, в которых мне удобно повседневно использовать `suex cat something` или `sush postgres` и тд без конфигов sudo
тут нет никакой загадки, это просто наглядный пример!
а в процессе работы у каждого может быть свой индивидуальный use-case.
а, кстати, есть плюс использования маски 4755 в контейнере.
если юзер не в группе suex, то в логах будет четко об это написано.
если поставить маску 4750, то в логах будет только "Permission denied", что может усложнить поиск проблемы из-за отсутствия контекста.
у вас отличное внимание! 👍 но я исправлять не буду, потому что в этом примере это не принципиально важно. даже с маской 4755 ничего посторонний пользователь сделать не сможет. он должен быть в группе suex по-любому
да, наша "боль" – двигатель инноваций 😁
имелось ввиду Unix, опечатка
так что там проверять, когда основная часть логики заключается в пяти строчках кода )) это не высшая математика, а базовый функционал Linux систем
suex/sush были написаны из необходимости для конкретного проекта и существующих процессов в действующей инфраструктуре потому что все имеющиеся решения это не совсем то "пальто", которое нужно на сегодняшний день для решения простых задач, а не ради каких-то "звезд".
проект лежит на гитхабе только потому что так удобнее.
вот, почитайте что такое sudo и как оно работает https://habr.com/ru/articles/1005738/
В этом то и дело, уважаемый пользователь. Sudo не делает ничего особенного. Всё уже встроено в ядро, Sudo только обвешивает всё различными правилами через кофниг
sudoers, который в наше время никому не нужен ни в облаке, ни в контейнерах.В Unix/Linux есть специальный бит прав setuid/setgid, его называют спец-бит на исполнение.Если он установлен у исполняемого файла, то программа запускается с effective UID/GID владельца файла, а не пользователя, который её запустил. Например, setuid-root позволяет обычному пользователю выполнить программу с правами root (только в рамках этого процесса), как это делает
passwd.да, друг, но не в звездах смысл. попробуй вникнуть в код и решение для начала. :D
мы - это те, кто в теме )) кто работает с Linux плотно не одно десятилетие
в нынешнее время контейнеризации и временно живущих Linux машин в облаке, CICD и тд, утилиты su, sudo теряют смысл из-за их громоздкости.
они были созданы в другой эпохе, которая уже в прошлом.
сейчас мы пользуемся простыми утилитами типа suex, sush https://github.com/mobydeck/suex
я тоже постил пару месяцев назад про MS-R1 https://habr.com/ru/posts/971862/
до сих пор не решил проблемы, о которых писал, но в целом он выполняет именно те функции, для которых я его купил. я доволен приобретением для хомлабы
у каждого свои задачи и свои требования к агентам. моё решение сделано для того, что мне нужно использовать каждый день, к примеру, ковыряясь в коде, написанном не мной за многие годы существования проекта.