очевидно, что portage не входит в группу root

А зачем, простите, защищать login.defs?

Затем, что там настройки shadow.

Да, но, как выяснилось, meson.build в некоторых случаях не пытается читать этот файл. А вот если пытается читать, то права на этот файл становятся актуальны. А у root'а проблем с доступом к этому файлу нет никогда.

Не составит ли тебе туда перечислить то, что у тебя там есть (только названия переменных) и сказать, что именно из этого должно быть настолько защищено?

Давай сравним выполнение удалить -рекурсивно-принудительно /* от рута и от пользователя.

Неправильная постановка вопроса. Ты сравниваешь эффект конкретной операции (взятой для примера), выполненной с разными привилегиями.

А нужна сравнивать количество возможностей совершить операцию приводящую к ущербу.

Любой ущерб нанесенный из под пользователя можно точно также нанести из под рута, но не наоборот. Соответственно неиспользование рута безопаснее.

Уже разобрались. Дело в systemd-resolved, который:

provides network name resolution to local applications

Подозреваю, если он криво настроен (например, выключен; либо старая кривая версия systemd: < 234, как в случае Саахрикту), то сетевые приложения могут глючить/тупить и т.д. Вообще, не важно, что настроено не по уму: конкретно systemd-resolved или любой другой костыль в системе, отвечающий за резолвинг (например, если в дистрибутиве нет systemd как такового), то могут наблюдаться глюки и лаги.

Там, как минимум, эти опции:

MAIL_DIR
PASS_MAX_DAYS
PASS_MIN_DAYS
PASS_WARN_AGE
UID_MIN
UID_MAX
SYS_UID_MIN
SYS_UID_MAX
GID_MIN
GID_MAX
SYS_GID_MIN
SYS_GID_MAX
CREATE_HOME
ENCRYPT_METHOD
CRYPT_ROUNDS
FAIL_DELAY
LOG_UNKFAIL_ENAB
LOG_OK_LOGINS
SYSLOG_SU_ENAB
SYSLOG_SG_ENAB
CONSOLE
SU_NAME
HUSHLOGIN_FILE
ENV_SUPATH
ENV_PATH
TTYGROUP
TTYPERM
ERASECHAR
KILLCHAR
UMASK
LOGIN_RETRIES
LOGIN_TIMEOUT
CHFN_RESTRICT
DEFAULT_HOME
USERGROUPS_ENAB

Тогда ты ссзб, не умеющий настраивать резолв локалхоста (что и приводит к тормозам на старте любой программы)

Судя по тому, из-за чего у него тормозил линукс с systemd, да.

Почти любая программа при запуске резолвит default route или типа того. Если не настроен resolv.conf или локальный dns сервер,ждёт таймаута и тормозит.

MAIL_DIR        /var/spool/mail
PASS_MAX_DAYS   99999
PASS_MIN_DAYS   0
PASS_MIN_LEN    5
PASS_WARN_AGE   7
UID_MIN                  1000
UID_MAX                 60000
SYS_UID_MIN               201
SYS_UID_MAX               999
GID_MIN                  1000
GID_MAX                 60000
SYS_GID_MIN               201
SYS_GID_MAX               999
CREATE_HOME     yes
UMASK           077
USERGROUPS_ENAB yes
ENCRYPT_METHOD SHA512 

Чем компрометация login.defs (см. мои выше) поможет потенциальному взломщику хотя бы в теории?

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

В случае sysvinit'а я просто прописывал dhclient в /etc/inittab. А тут инсталлятор дистрибутива для домохозяек сделал соответствующие настройки сам, и в деталях этих настроек я не успел до конца разобраться. В той же Федоре в них можно и не вникать. Там свежий systemd, и всё перенастраивается автоматически само. А тут где-то что-то изначально не срослось. Но, с обновлением systemd новый systemd всё починил.

Эх... /etc/resolv.conf спасёт.

Любой ущерб нанесенный из под пользователя можно точно также нанести из под рута, но не наоборот. Соответственно неиспользование рута безопаснее.

Намного ли? Как я уже говорил, ущерб установленной системе решается её полной переустановкой. Это сколько? Час примерно? Можно даже не из бекапа раскатывать. А ущерб от потери файлов пользователя восстанавливается примерно за время, прошедшее от предыдущего бекапа. Иногда это потеря рисунков, которые заново сложно перерисовать так же удачно, например. На фоне таких потерь час практически механической работы — почти ничто.

Так что не сильно отличается.

Ну так тот же dhclient периодически перезаписывает /etc/resolv.conf. Детали работы других DHCP клиентов пока ещё не выяснял. А вот при статическом IP'шнике можно и руками /etc/resolv.conf настраивать.

Видимо, подразумевается, что собирать надо под _особым_ пользователем, ни под рутом, ни под своим. Тогда имеем просто вид песочницы. И это полезно. А с твоими соображениями согласен.

Звучит разумно. Если ещё какая-нибудь автоматизация вроде слоя ФС поверх, который после работы выбрасывается, тогда вообще хорошо.

Саахрикту и системдэ

/0

</thread>

А вообще Поттеринг перелогинься, а лучше на винфак вали, саахрикту не такой, он КОИ-8 любит.

может притормаживать даже mc, которому в ядерной консоли

Ему и не требуется, если без поддержки smb собирать.

Так ведь всё равно make install под рутом запускается.

Зачем это? Он точно так же от юзера запускается, и ставит всё в какой-нибудь $buildroot. Или я какую-то нить разговора упустил?..

ALT,

И что, в ALT не от рута не собирается? Точно уверен? Проверял? :-)

Звучит разумно.

Так оно так и делается у многих. А ещё сборку можно делать на сильно шумящем быстром сервере, который стоит где-то не близко. И там вынос юзера для сборки вообще ничего не значит.

У тебе система без PAM?

Нет, не проверял. Я проверял права на тот файл. В перечисленных дистрибутивах в пакетах права именно такие же.

Потом уже выяснили, что в ряде случаев meson.build systemd может и не читать тот файл. Но, у меня получилось наступить на эти грабли.

Тогда эти твои секретные опции из login.defs в рантайме вообще не используются.

При включенном PAM часть опций может им переопределяться, да.

Или я какую-то нить разговора упустил?

ТС написал, что собирает под рутом. Ему сразу начали читать мантру «не собирай под рутом». Мне стало интересно, а какой, собственно, смысл? Если уж опасаешься проблем, собирай в песочнице. Есть chroot/schroot, есть контейнеры. Но если собираешь под своим пользователем, по уровню потенциального урона это не сильно отличается от сборки под рутом. Но почему-то сборка под своим пользователем считается нормальной, а сборка под рутом — предосудительной.

А я не вижу разницы.

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

Сборка под пользователем может добавить в .bashrc что-нибудь нехорошее. Например, alias sudo=smth. А дальше — получить данные других пользователей. Ну и вдобавок: те, кто ставят через make install, запускают make install от рута. И какой смысл тогда в сборке не из-под рута?

собрать может, если у пользователя есть доступ на чтение, а удалить их нет.

p.s. у меня нет sudo, но речь даже не о преднамеренном порче, а ошибке в скриптах запуска сборки

опять же, в том же portage выполнение make install происходит в sandbox и только по его завершению сам portage распихивает файлы и ругается, емнип, если что-то вдруг в результате распихивания должно перезаписаться.

Ну так ведь ТСу не говорят фи на сборку под обычным пользователем, не советуют собирать в песочнице. А фи говорят только про сборку под рутом.

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

не, ну если пакету довереряю и он не неделю назад появился, то я под пользователем собираю в домашнем каталоге: скачал, распаковал же я им, а в рут это ж ещё логинился нужно.

Удобство — тоже вполне себе причина. Но как причина почему-то не было озвучено.

Леннарт сделал говно, из которого Федора сделала конфетку.

Нет, не проверял.

Понятно. Для справки, в ALT специально сделано так, что rpm НЕ может осуществлять сборку пакета от root.

Но почему-то сборка под своим пользователем считается нормальной, а сборка под рутом — предосудительной.

Если так подходить к вопросу, то, действительно, почти без разницы. Но «почти» тоже имеет смысл: бакап home может быть, в каком-нибудь /mnt тоже может быть что-то смонтировано и т.п. Ну и сборочный пользователь может быть отдельный, и, как я уже написал, где-то на мощном сервере.

Ну так я, повторяю, и не говорил, что, якобы, в ALT'е можно собирать пакеты от root'а. Мне задали вопрос: «В каких дистрибутивах на конкретный файл /etc/login.defs стоят конкретные права 640?». И я на него ответил. Ни больше, ни меньше. Конкретно про права на конкретный файл.

бакап home может быть

Всё-таки очень желательно держать бекап где-то отдельно. Желательно, чтобы он был только для добавления.

Не работает

mount: /sys/kernel/debug: none already mounted on /sys/kernel/debug.

ЧЯДНТ? Оно не предусматривает, что debugfs может быть уже смонтирована? И раз оно на ведро не ругается — значит, в нём уже нужное включено всё?

В общем случае пакет можно собрать статически и запускать только от юзверя, не распихивая по системным директориям, так что это таки минус.

Типа надо понимать DOS, чтобы сидеть под DOS.

Ты тоже заметил, что ЛОРчан незаметно подменяют?

Чойта сдох? его вон на вяленый портируют даже.

У меня вон ваще секунд 18 запускался, проверил щя. Причём последние 5 секунд уже висел почищенный ncurses, но ещё не прорисованный, терминал.

и его нужно патчить

Ты видел писанный смузихлёбами-девопсами говнософт типа openstack? Там скрипт инсталляции вообще накатывает туеву хучу зависимостей, автоматически, и так и написано — на существующей системе лучше эту срань лучше не запускать, а то попортит всё. И во все поля всякие sudo, в результате чего на неубунтах оно заводится проблематично.