forum.opennet.ru - "Уязвимости в пакетных менеджерах Nix, Lix и Guix" (50)

"Уязвимости в пакетных менеджерах Nix, Lix и Guix"

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
Сообщение от opennews (ok), 25-Июн-25, 14:03
В пакетных менеджерах GNU Guix, Nix и Lix выявлены уязвимиости (Nix, Guix, Lix), позволяющие выполнить код с правами пользователей, под которыми запускаются сборочные задания (например, nixbld* в Nix/Lix), что может использоваться для записи своих данных в сборочное окружение и внесения изменений в сборочный процесс. Проблемы присутствуют в фоновых процессах guix-daemon и nix-daemon, применяемых для организации доступа непривилегированных пользователей к сборочным операциям... Подробнее: https://www.opennet.me/opennews/art.shtml?num=63464
Ответить \| Правка \| Cообщить модератору

Оглавление

Эти уязвимости кого надо уязвимости Нужно больше дистрибутивов и больше систем, , IMBird (ok), 14:03 , 25-Июн-25, (1) +3

И в целом там и о расте адекватно задумываются - как о возможности, а не панацее, bOOster (ok), 14:21 , 25-Июн-25, (10)

Исходный код раст открыт Как он с GNU уживётся Если проприетарный раст будет и, Аноним (-), 14:50 , 25-Июн-25, (18) –1

И самые неуловимые, как Джо , Аноним (12), 14:28 , 25-Июн-25, (12) +1

Это раньше было что Джо неуловимый потому что никому не нужен По текущим нормам, Аноним (35), 15:45 , 25-Июн-25, (35)

Больше пакетных менеджеров и пакетов, пакетов, пакетов , Аноним (-), 14:44 , 25-Июн-25, (16)
В FreeBSD до недавнего времени скачивание и сборка производились под рутом, без , Аноним (19), 14:50 , 25-Июн-25, (19)

Главное, не забывать повторять услышанное в перепеве Рабиновича кстати, сборка, Аноним (43), 16:44 , 25-Июн-25, (43)

Вам же хорошо сказаноПосмотрите на дату коммитаКогда там bsd появилась, в каком , Аноним (61), 00:36 , 26-Июн-25, (61) –1

Всю жизнь рут требовался только для make install , Аноним (55), 22:36 , 25-Июн-25, (55)

Топорные топоры из каменного века, не способные почти ни на что , Аноним (61), 15:38 , 25-Июн-25, (32) –5

Иногда топоры покрайней мере надёжные, а все новомодные пукалки не вызывают дове, Аноним (35), 15:48 , 25-Июн-25, (36) +2

Я надеюсь, что еду себе вы готовите на костре, дрова для которого, срублены каме, Аноним (61), 15:56 , 25-Июн-25, (40) –3
Они у вас лишь иногда надёжные А всё остальное время тоже не вызывают доверия , Голум (?), 17:07 , 25-Июн-25, (44)

Какие созвучные имена пакетных менеджеров, прямо как из сказки про трех поросят, Анонимище (?), 14:04 , 25-Июн-25, (2) +9

Я злой и страшный серый волк, я в поросятах Wпакетных менеджерах знаю толк , Кошкажена (?), 15:38 , 25-Июн-25, (33)

Фоновые процессы для установки программ, вот это клиника, Fracta1L (ok), 14:08 , 25-Июн-25, (3) +4

Почему , Аноним (-), 14:14 , 25-Июн-25, (8) –1
Фоновые процессы для монтирования размонтирования, для вывода звука, для вывода , Аноним (17), 14:49 , 25-Июн-25, (17) +1

Это всё можно понять, потому что для нормальной комфортной работы этих подсистем, Fracta1L (ok), 15:17 , 25-Июн-25, (26) +1

в унбунте до сих пор нельзя выключить попапы обновлений без rm -rf что-то-там , 12yoexpert (ok), 15:24 , 25-Июн-25, (27)
Событие собери скачай такой-то дериватив Это позволяет обычным пользователям , Аноним (17), 15:25 , 25-Июн-25, (29)
Сразу видно ыксперда Событие - пользователь инициировал сборку чего-то там Дал, Аноним (61), 15:44 , 25-Июн-25, (34) +2

и для этого всего нужен демон это же обычный сценарий, который можно и по крону, Аноним (48), 19:22 , 25-Июн-25, (48)

А крон давно демоном быть перестал Когда я вызываю nix, то хочу получить результ, Аноним (61), 21:11 , 25-Июн-25, (52)

так для него это необходимость, один демон, исполняющий периодически необходимые, Аноним (48), 23:06 , 25-Июн-25, (58)

Количество демонов с начала 70-ых возросло Очень сильно Тот же snap из убунты,, Аноним (61), 00:27 , 26-Июн-25, (59)

Дайте определение понятия демон служба , я думаю вы не понимаете значение этого, Аноним (48), 01:01 , 26-Июн-25, (63)

Если есть меж-процессное взаимодействие, значит процессов как минимум два На эт, Аноним (17), 03:23 , 26-Июн-25, (67)

Вы сами на свои вопросы и отвечаете, нет Делаете окружение пользователя-сборщик, Аноним (68), 08:30 , 26-Июн-25, (68)

emacs --daemon передаёт вам пламенный привет Условный vs code или phpstorm тоже, Аноним (61), 00:32 , 26-Июн-25, (60)

Ну вот уже прогресс, а теперь вопрос, возможно ли клиент-серверную архитектуру П, Аноним (48), 01:15 , 26-Июн-25, (64)

Откройте unut файл nixos-container, и обнаружите, что для котнейнера nix как раз, Аноним (61), 09:26 , 26-Июн-25, (69)

О про Nix Все пытаюсь узнать - можно ли одной общей настройкой сделать сборку св, Аноним (4), 14:10 , 25-Июн-25, (4)

Flakes Overlays вам в помощь , Amerigo (?), 14:26 , 25-Июн-25, (11)

Быстро просмотрел Но, кажется, там нет возможности задать использование разных , Аноним (4), 14:55 , 25-Июн-25, (20)

Это ж сколько там будет версий Попробуй взять калькулятор и рассчитать, сколько, Аноним (17), 15:06 , 25-Июн-25, (23)
Можно, map reduce изобретён Ну разумеется, если исходный код и компилятор такое, Аноним (61), 15:36 , 25-Июн-25, (31)
А вообще, в никсе так не принято Да и нигде так не принято Ты оформляешь пак, Аноним (17), 15:48 , 25-Июн-25, (37) +1

Не совсем Вот есть, например pkgs pkgsMusl, который хранит в себе дерево пакето, Аноним (61), 16:03 , 25-Июн-25, (41)
Очевидно это в общем случае В частном - у меня используется, скажем, 5 библиотек, Аноним (57), 22:57 , 25-Июн-25, (57)

Это тот самый NIX который используется в самой лучшей по мнению её фанатов Nix, Аноним (-), 14:11 , 25-Июн-25, (5) +2

Ага , Аноним (-), 14:14 , 25-Июн-25, (7)
Что же безопасно , Аноним (9), 14:19 , 25-Июн-25, (9)

Лабораторная уязвимость В реальности недостижимо , Шарп (ok), 14:40 , 25-Июн-25, (15) +3

Вообще-то стандартная Делаешь свою сборку пытающуюся использовать эту уязвимост, Аноним (4), 14:58 , 25-Июн-25, (22)
Поди што и чинить не надо Хотя не rhel с ubuntu ой - на той машине с NIX ом , User (??), 15:12 , 25-Июн-25, (24)

Не доверяю я всем этим никсам Раздражает все это жуткое дробление, каждый норов, Аноним (46), 17:46 , 25-Июн-25, (46)

Вам лишь бы зарегулировать и патрулей наставить, ей богу , аноним1277zx (?), 18:01 , 25-Июн-25, (47) +2
Типичный вахтёр - сам ничего не делает, а другим запрещает Осуждаю , Аноним (61), 21:14 , 25-Июн-25, (53) –1

Сообщения [Сортировка по времени | RSS]

1. "Уязвимости в пакетных менеджерах Nix, Lix и Guix" +3 +/–

Сообщение от IMBird (ok), 25-Июн-25, 14:03

Эти уязвимости кого надо уязвимости.
Нужно больше дистрибутивов и больше систем, чтобы никто адекватный об аудите даже не задумывался.
Пакетные системы BSD и гайки всё ещё самые адекватные по реализации.

Ответить | Правка | Наверх | Cообщить модератору

10. "Уязвимости в пакетных менеджерах Nix, Lix и Guix" +/–

Сообщение от bOOster (ok), 25-Июн-25, 14:21

И в целом там и о расте адекватно задумываются - как о возможности, а не панацее..

Ответить | Правка | Наверх | Cообщить модератору

18. "Уязвимости в пакетных менеджерах Nix, Lix и Guix" –1 +/–

Сообщение от Аноним (-), 25-Июн-25, 14:50

Исходный код раст открыт? Как он с GNU уживётся? Если проприетарный раст будет использоваться, то GNU уже будет не торт. Весь смысл потеряется. Люди тогда прежде чем покупать устройство под PureOS, могут и задуматься - а зачем? Устройства Librem не такие уж и дешевые как кажутся: https://puri.sm/products/

Ответить | Правка | Наверх | Cообщить модератору

12. "Уязвимости в пакетных менеджерах Nix, Lix и Guix" +1 +/–

Сообщение от Аноним (12), 25-Июн-25, 14:28

>Пакетные системы BSD и гайки всё ещё самые адекватные по реализации.
И самые неуловимые, как Джо.

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

35. "Уязвимости в пакетных менеджерах Nix, Lix и Guix" +/–

Сообщение от Аноним (35), 25-Июн-25, 15:45

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

Ответить | Правка | Наверх | Cообщить модератору

16. "Уязвимости в пакетных менеджерах Nix, Lix и Guix" +/–

Сообщение от Аноним (-), 25-Июн-25, 14:44

Больше пакетных менеджеров и пакетов, пакетов, пакетов!

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

19. "Уязвимости в пакетных менеджерах Nix, Lix и Guix" +/–

Сообщение от Аноним (19), 25-Июн-25, 14:50

>Пакетные системы BSD и гайки всё ещё самые адекватные по реализации.
В FreeBSD до недавнего времени скачивание и сборка производились под рутом, без какого-либо ограничения доступа к системе.

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

43. "Уязвимости в пакетных менеджерах Nix, Lix и Guix" +/–

Сообщение от Аноним (43), 25-Июн-25, 16:44

> В FreeBSD до недавнего времени скачивание и сборка производились под рутом, без какого-либо ограничения доступа к системе.
Главное, не забывать повторять услышанное в перепеве Рабиновича (кстати, "сборка" чего? pkg ничего не собирает)
commit c239d131dc920d6f3dead18a8e9a772372fe9578
Author: Bryan Drewery <bryan@shatow.net>
Date:   Wed Jan 31 15:53:19 2018 -0800
    audit: Drop privileges after opening the files/database but before parsing.
commit f3b0469eb8669967d76d18fb56222853ca30871d
Author: Baptiste Daroussin <bapt@FreeBSD.org>
Date:   Fri Nov 11 22:18:25 2016 +0100

    Stop dropping privileges when fetching as it causes more issues than it
    solved
commit fcceab3f1e0ae780e8a91918488aab3ba5f5ea1c
Author: Baptiste Daroussin <bapt@FreeBSD.org>
Date:   Sat Aug 20 01:17:34 2016 +0200

    drop privileges when using libfetch

Вот еще немного "на закуску"

pkg_repo.c
   /*
   * We need to load this pubkey from meta
   */

   if (pkg_emit_sandbox_get_string(pkg_repo_meta_extract_pubkey, &cbdata
pkg_sandbox.c
int
pkg_handle_sandboxed_get_string(pkg_sandbox_cb func, char **result, int64_t *len,
                void *ud)
...
/* Here comes child process */
        close(pair[1]);
        pkg_drop_privileges();
        rl_zero.rlim_cur = rl_zero.rlim_max = 0;
        if (setrlimit(RLIMIT_NPROC, &rl_zero) == -1)
                err(EXIT_FAILURE, "Unable to setrlimit(RLIMIT_NPROC)");
#ifdef HAVE_CAPSICUM
#ifndef PKG_COVERAGE
        if (cap_enter() < 0 && errno != ENOSYS) {
void
pkg_drop_privileges(void)
{
        struct passwd *nobody;
        if (geteuid() == 0) {
                nobody = getpwnam("nobody");
                if (nobody == NULL)
                        errx(EXIT_FAILURE, "Unable to drop privileges: no 'nobody' user");
                setgroups(1, &nobody->pw_gid);

Ответить | Правка | Наверх | Cообщить модератору

61. "Уязвимости в пакетных менеджерах Nix, Lix и Guix" –1 +/–

Сообщение от Аноним (61), 26-Июн-25, 00:36

>Главное, не забывать повторять услышанное в перепеве Рабиновича
Вам же хорошо сказано
>до недавнего времени
Посмотрите на дату коммита
>2018, 2016
Когда там bsd появилась, в каком году? Солько лет так жили - 10, 20, а то может и все 40?

Ответить | Правка | Наверх | Cообщить модератору

55. "Уязвимости в пакетных менеджерах Nix, Lix и Guix" +/–

Сообщение от Аноним (55), 25-Июн-25, 22:36

Всю жизнь рут требовался только для make install.

Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

32. "Уязвимости в пакетных менеджерах Nix, Lix и Guix" –5 +/–

Сообщение от Аноним (61), 25-Июн-25, 15:38

>Пакетные системы BSD и гайки всё ещё самые адекватные по реализации.
Топорные топоры из каменного века, не способные почти ни на что?

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

36. "Уязвимости в пакетных менеджерах Nix, Lix и Guix" +2 +/–

Сообщение от Аноним (35), 25-Июн-25, 15:48

Иногда топоры покрайней мере надёжные, а все новомодные пукалки не вызывают доверия.

Ответить | Правка | Наверх | Cообщить модератору

40. "Уязвимости в пакетных менеджерах Nix, Lix и Guix" –3 +/–

Сообщение от Аноним (61), 25-Июн-25, 15:56

Я надеюсь, что еду себе вы готовите на костре, дрова для которого, срублены каменным топором. Мангал, печь и другихе хипсторские смузитехнологии не используете.

Ответить | Правка | Наверх | Cообщить модератору

44. "Уязвимости в пакетных менеджерах Nix, Lix и Guix" +/–

Сообщение от Голум (?), 25-Июн-25, 17:07

Они у вас лишь иногда надёжные? А всё остальное время тоже не вызывают доверия?

Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

2. "Уязвимости в пакетных менеджерах Nix, Lix и Guix" +9 +/–

Сообщение от Анонимище (?), 25-Июн-25, 14:04

Какие созвучные имена пакетных менеджеров, прямо как из сказки про трех поросят

Ответить | Правка | Наверх | Cообщить модератору

33. "Уязвимости в пакетных менеджерах Nix, Lix и Guix" +/–

Сообщение от Кошкажена (?), 25-Июн-25, 15:38

> Какие созвучные имена пакетных менеджеров, прямо как из сказки про трех поросят
Я злой и страшный серый волк, я в поросятах^Wпакетных менеджерах знаю толк!

Ответить | Правка | Наверх | Cообщить модератору

3. "Уязвимости в пакетных менеджерах Nix, Lix и Guix" +4 +/–

Сообщение от Fracta1L (ok), 25-Июн-25, 14:08

Фоновые процессы для установки программ, вот это клиника

Ответить | Правка | Наверх | Cообщить модератору

8. "Уязвимости в пакетных менеджерах Nix, Lix и Guix" –1 +/–

Сообщение от Аноним (-), 25-Июн-25, 14:14

Почему?

Ответить | Правка | Наверх | Cообщить модератору

17. "Уязвимости в пакетных менеджерах Nix, Lix и Guix" +1 +/–

Сообщение от Аноним (17), 25-Июн-25, 14:49

Фоновые процессы для монтирования/размонтирования, для вывода звука, для вывода окошек, для показа диалога "Открыть файл", для отправки сообщения в третий процесс через шину, для всего подряд. А ты тут про какую-то установку программ.

Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

26. "Уязвимости в пакетных менеджерах Nix, Lix и Guix" +1 +/–

Сообщение от Fracta1L (ok), 25-Июн-25, 15:17

Это всё можно понять, потому что для нормальной комфортной работы этих подсистем нужно ловить события. А какие к чёрту события могут быть у менеджера пакетов, что это потребовало демона?

Ответить | Правка | Наверх | Cообщить модератору

27. "Уязвимости в пакетных менеджерах Nix, Lix и Guix" +/–

Сообщение от 12yoexpert (ok), 25-Июн-25, 15:24

в унбунте до сих пор нельзя выключить попапы обновлений без rm -rf что-то-там?

Ответить | Правка | Наверх | Cообщить модератору

29. "Уязвимости в пакетных менеджерах Nix, Lix и Guix" +/–

Сообщение от Аноним (17), 25-Июн-25, 15:25

Событие "собери/скачай такой-то дериватив". Это позволяет обычным пользователям пользоваться услугами сборщика. Почему так сделано? Ответ в твоем комменте: "для нормальной комфортной работы".

Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

34. "Уязвимости в пакетных менеджерах Nix, Lix и Guix" +2 +/–

Сообщение от Аноним (61), 25-Июн-25, 15:44

>А какие к чёрту события могут быть у менеджера пакетов, что это потребовало демона?
Сразу видно ыксперда. Событие - пользователь инициировал сборку чего-то там. Далее, от непривилегированного пользователя запускается скачиваение и сборка всего этого дела в чистом окружении. Добавим сюда тот факт, что это системный пакетный менеджер, который кеширует результаты сборок, делая их разделяемыми для всей системы целиком, а не только для текущего проекта, удаляет ставшие ненужными пакеты, занимается перезапуском различных служб и так далее.

Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

48. "Уязвимости в пакетных менеджерах Nix, Lix и Guix" +/–

Сообщение от Аноним (48), 25-Июн-25, 19:22

> и так далее
и для этого всего нужен демон? это же обычный сценарий, который можно и по крону запустить, демон зачем?

Ответить | Правка | Наверх | Cообщить модератору

52. "Уязвимости в пакетных менеджерах Nix, Lix и Guix" +/–

Сообщение от Аноним (61), 25-Июн-25, 21:11

>это же обычный сценарий, который можно и по крону запустить
А крон давно демоном быть перестал?
>который можно и по крону запустить
Когда я вызываю nix, то хочу получить результат сразу же, а не в следующий день. Минимальное разрешение крона - минута. Далее, у вас будет задача вернуть результат из крона именно той программе, которая его вызвала, поскольку в NixOS nix может вызываться достаточно часто.
>демон зачем?
Для обработки запросов пользователя. Это точно так же, как условный nginx - вы отправляете запрос, его прямо сейчас обрабатывают и выдают ответ. Работа с пакетами происходит в изолированном окружении, исходники вначале скачиваются, а потом уже без интернета собираются. Это уже тянет как минимум на условный подман. В условном дебине или арче исходник может во-первых выкачать бекдор прямо в момент сборки, во-вторых, там нет никакой проверки описания пакета, например, можно забыть, что пакету нужен gcc, и если gcc уже стоит в системе, то пакет молча соберётся, но его спецификация будет неверной. это одна из причин, по какой для сборки рекомендуют создавать отдельное окружение. Далее, добавим тот факт, что это системный пакетный менеджер. У условного подмана практически нет кеширования образов. Незначительные изменения докерфайла, и всё будет перекачиваться/пересобираться повторно. Условные bash будет в каждом образе качаться независимо друг от друга. Далее, возьмём удаление пакетов: привычного apt remove в nix нет, поскольку пакеты не ставятся глобально. Вместо этого применяется стратегия со сборкой мусора - есть несколько корней, которые рекурсивно удерживают пакеты от удаления. Как следствие, во время сборки мусора нужно точно знать, какие пакеты используются прямо сейчас, а какие - нет. Есть текущая сборка, есть предыдущие, на которые пользователь может откатится простой перезагрузкой, есть systemd контейнеры, есть анонимные окружения, запущенные через nix-shell -p, есть окружения запущенные через nix файлы. Всё это дело и удерживает пакеты в системе. Условный apt в убунте намертво блокируется, если фоном выполняется какая-то операция, например проверяется наличие обновлений, так как может выполняться только один экземпляр apt, в противном случае один apt поставит пакет с зависимостью о libfoo, а второй эту зависимость снесёт как ставшую ненужной. Подману абсолютно всё равно, сколько libfoo у вас есть, для исправления этого даже специальные файловые системы изобретают.

Ответить | Правка | Наверх | Cообщить модератору

58. "Уязвимости в пакетных менеджерах Nix, Lix и Guix" +/–

Сообщение от Аноним (48), 25-Июн-25, 23:06

> А крон давно демоном быть перестал?
так для него это необходимость, один демон, исполняющий периодически необходимые сценарии, а не на каждый чих свой демон.
> Когда я вызываю nix, то хочу получить результат сразу же, а не в следующий день.
ну а демон зачем вам, если вы просто запускаете сценарий? Крон это пример где демон - необходимость, когда необходимо периодически запускать сценарии.
> Для обработки запросов пользователя.
понятие "интерактивная программа" незнакома?
> Это точно так же, как условный nginx - вы отправляете запрос, его прямо сейчас обрабатывают и выдают ответ.
любая вызванная команда выполняется прямо сейчас и выдает ответ. Nginx - служба по определению, так как работает 24 на 7. В установке (сборке) софта нет необходимости службы 24 на 7. Почему у вас калькулятор еще не служба или там текстовый редактор?
> Работа с пакетами происходит в изолированном окружении, исходники вначале скачиваются, а потом уже без интернета собираются.
неважно как там все это происходит, тут главное что это происходит по действию пользователя при необходимости, и необходимости в 24 на 7 нет.
> это одна из причин, по какой для сборки рекомендуют создавать отдельное окружение
вы лучше про причину необходимости демона напишите

Ответить | Правка | Наверх | Cообщить модератору

59. "Уязвимости в пакетных менеджерах Nix, Lix и Guix" +/–

Сообщение от Аноним (61), 26-Июн-25, 00:27

>а не на каждый чих свой демон.
Количество демонов с начала 70-ых возросло. Очень сильно. Тот же snap из убунты, например.
>ну а демон зачем вам, если вы просто запускаете сценарий?
Затем, что кто-то должен слушать /nix/var/nix/daemon-socket/socket.
>понятие "интерактивная программа" незнакома?
Очень много интерактивных программ живёт с демонами. Как тот же докер. Как pulseaudio, pipewire. Уже вам четыре программы в одном сообщении, но суммарно их гораздо больше.
>любая вызванная команда выполняется прямо сейчас и выдает ответ.
Не любая. Для СУБД существует клиент и сервер, даже если база запущена на одном устройстве. Существуют исключения, игрушечные СУБД типа sqlite, но именно исключения.
>В установке (сборке) софта нет необходимости службы 24 на 7.
Вы глубоко неправы. Демон нужен не для 24 на 7, а как единая точка входа, обрабатывающая все запросы. Как условный xorg, wayland композитор, pulseaudio, systemd, да даже minecraft, или условный python -m http.server.
Это в дебиане/арче софт ставится разово, или не ставится вообще, так как поставить две версии libfoo без танца с бубнами нельзя, и на этом история заканчивается. Как там было в комиксе xkcd, про ноутбук зону отчуждения, на котором куча установок python. В NixOS даже для установленного софта нужен nix, например для компиляции. И каждый раз, когда нужно запустить компиляцию, вы заходите в каталог с проектом и разворачиваете окружение. Ибо одному проекту нужна libfoo 0.5 версии, а второму - 2. Более того, в некоторых случаях nix может идти в самом начале shebang-а - у вас каждый запуск софта будет запускаться nix.
>неважно как там все это происходит
Как раз таки важно. Вы до сих пор не привели ни одного примера, как достичь аналогичного функционала без демона. Ни по воспроизводимой сборке, ни по безопасной сборке, ни по сохраниению целосности системы, ни по удобству использования, ни по лени, ни по кешированию. Уже этих свойств более чем достаточно.
>и необходимости в 24 на 7 нет.
Вы вначале придумали аргумент 24/7, и теперь его повторяете.
>вы лучше про причину необходимости демона напишите
Вам уже написали кучу причин, но вы притворяетесь что их нет.

Ответить | Правка | Наверх | Cообщить модератору

63. "Уязвимости в пакетных менеджерах Nix, Lix и Guix" +/–

Сообщение от Аноним (48), 26-Июн-25, 01:01

> Количество демонов с начала 70-ых возросло. Очень сильно. Тот же snap из убунты, например.
Дайте определение понятия демон (служба), я думаю вы не понимаете значение этого термина.
> Очень много интерактивных программ живёт с демонами. Как тот же докер. Как pulseaudio, pipewire. Уже вам четыре программы в одном сообщении, но суммарно их гораздо больше.
Я не вижу в этом списке ни калькулятора, не текстового редактора, ни сапера (игра), но вероятно в этом списке явно должен быть виджет погоды или температуры процессора. Так в чем дело?
> Не любая. Для СУБД существует клиент и сервер, даже если база запущена на одном устройстве.
Ну существует, и что мы не запускаем клиент? Мы не получаем интерактивного приглашение? В чем дело? А сервер СУБД - служба, и служит она не только мне по определению службы. А клиент - это интерактивная программа запускаемая при необходимости, почему у вас клиент не служба?
> Вы глубоко неправы. Демон нужен не для 24 на 7, а как единая точка входа, обрабатывающая все запросы.
У вас шо там другого способа меж-процессного взаимодействия не нашлось? Правильно говорит  Fracta1L - это клиника.
> Как условный xorg, wayland композитор, pulseaudio, systemd, да даже minecraft, или условный python -m http.server.
Почему в этом списке нет калькулятора?
> Вы до сих пор не привели ни одного примера, как достичь аналогичного функционала без демона.
Когда поймете для чего необходимы демоны, тогда поймете как достичь.
> Уже этих свойств более чем достаточно.
Ей ГНУ-шники, почему ваш gcc до сих пор не демон? Вы можете не отвечать, вопрос не вам.
> Вы вначале придумали аргумент 24/7, и теперь его повторяете.
Потому-что до вас элементарно не доходит значение слова демон (служба)
> Вам уже написали кучу причин, но вы притворяетесь что их нет.
Отправьте эти причины ГНУ-шникам, чтобы в следующей версии gcc был демоном.

Ответить | Правка | Наверх | Cообщить модератору

67. "Уязвимости в пакетных менеджерах Nix, Lix и Guix" +/–

Сообщение от Аноним (17), 26-Июн-25, 03:23

> другого способа меж-процессного взаимодействия не нашлось?
Если есть меж-процессное взаимодействие, значит процессов как минимум два. На этом коммент можно завершать, так как ты уже сам постулируешь необходимость демона (второй процесс из двух). Но продолжим:
"Другой способ меж-процессного взаимодействия" -- это активация по требованию. И он требует демон, который будет активировать другого демона:
1. Прога А обращается к шине (демону d-bus) с просьбой активировать прогу Б.
2. Демон активирует (запускает) прогу Б.
3. Прога Б регистрируется в шине d-bus в качестве демона, отвечающего на запросы.
4. Прога А и прога Б (два процесса) общаются меж собой через шину (через демон d-bus, третий процесс).
Как видишь, альтернатива двум процессам -- это три процесса.
Рассмотрим другой случай: прога А запускает напрямую прогу Б без всяких демонов. В этом случае прога Б будет иметь те же права, что и прога А, а значит уже не сможет запускать билдеров, напрямую записывать в /nix/store результаты и выполнять прочие вещи, необходимые с точки зрения nix. Поэтому прогу А придется запускать из-под рута. Это неудобный вариант.
При желании, можно отказаться от демона nix, там это именуется "single-user mode" https://nix.dev/manual/nix/2.24/installation/nix-security -- со всеми вытекающими ограничениями. В NixOS правда никто так не делает: иметь демона тупо удобно, а без демона тупо неудобно. Когда я запускаю VSCode, и в нем поднимается окружение из flake.nix + direnv, я не хочу вводить рутовый пароль, чтоб скачать/собрать зависимости моего проекта. Спасибо демону, который слушает мои просьбы собрать/скачать зависимости и делает все необходимое с рутовыми правами, которые у него есть (а у меня нет на момент запуска VSCode).

Ответить | Правка | Наверх | Cообщить модератору

68. "Уязвимости в пакетных менеджерах Nix, Lix и Guix" +/–

Сообщение от Аноним (68), 26-Июн-25, 08:30

> Вы до сих пор не привели ни одного примера, как достичь аналогичного функционала без демона. Ни по воспроизводимой сборке, ни по безопасной сборке, ни по сохраниению целосности системы, ни по удобству использования, ни по лени, ни по кешированию. Уже этих свойств более чем достаточно.
> И каждый раз, когда нужно запустить компиляцию, вы заходите в каталог с проектом и разворачиваете окружение.
Вы сами на свои вопросы и отвечаете, нет? Делаете окружение пользователя-сборщика пакетов, компилируете пакет с указыванием нужного ABI (а не libчто-то.so), собираете в тарбол и файликом, который говорит, какой конкретно ABI мы хотим.
Вы проблему версий "одному нужно то, другому это" из пальца высасываете банальным нежеланием напрямую пользоваться инструментами, которые у вас в линуксе уже есть.

Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

60. "Уязвимости в пакетных менеджерах Nix, Lix и Guix" +/–

Сообщение от Аноним (61), 26-Июн-25, 00:32

>Почему у вас калькулятор еще не служба или там текстовый редактор?
emacs --daemon передаёт вам пламенный привет. Условный vs code или phpstorm тоже где-то внутри обениваются ipc, ибо запуск нового экземпляра открывает не новое окно редактора, а вкладку в текущем сеансе. Да даже браузеры, не важно firefox или chrome тоже живут по такой логике. Не пишите то, в чём не разбираетесь.

Ответить | Правка | К родителю #58 | Наверх | Cообщить модератору

64. "Уязвимости в пакетных менеджерах Nix, Lix и Guix" +/–

Сообщение от Аноним (48), 26-Июн-25, 01:15

> emacs --daemon передаёт вам пламенный привет.
Ну вот уже прогресс, а теперь вопрос, возможно ли клиент-серверную архитектуру ПО реализовать без понятия службы? Вы понимаете что сервер может быть удаленным?
"""
Emacs supports a client/server mode where new files are opened in a running instance of Emacs. This saves you from having to load configuration and packages for every new file you open and allows the sharing of buffers between different emacs frames opened externally. This involves two configuration steps: using EmacsClient to open files, and running the Emacs server. This page focuses on how to launch the server at startup, a.k.a. daemon mode. This feature was introduced in Emacs 23.1
"""
> Условный vs code или phpstorm тоже где-то внутри обениваются ipc, ибо запуск нового экземпляра открывает не новое окно редактора, а вкладку в текущем сеансе.
Клиент-серверная архитектура - это не ipc!
> Не пишите то, в чём не разбираетесь.
лол, точно клиника.

Ответить | Правка | Наверх | Cообщить модератору

69. "Уязвимости в пакетных менеджерах Nix, Lix и Guix" +/–

Сообщение от Аноним (61), 26-Июн-25, 09:26

>Вы понимаете что сервер может быть удаленным?
Откройте unut файл nixos-container, и обнаружите, что для котнейнера nix как раз таки удалённый, обращается к хостовому. Вы вообще nix хоть раз своими глазами видели?

Ответить | Правка | Наверх | Cообщить модератору

4. "Уязвимости в пакетных менеджерах Nix, Lix и Guix" +/–

Сообщение от Аноним (4), 25-Июн-25, 14:10

О про Nix.
Все пытаюсь узнать - можно ли одной общей настройкой сделать сборку своего пакета во множестве вариантов (все используемые библиотеки всех версий)?
Типа написал один конфиг сборки - и генерируешь пакеты своей программы на каждую комбинацию библиотек.
Иначе смысла для разработчиков в Nix особо не вижу.

Ответить | Правка | Наверх | Cообщить модератору

11. "Уязвимости в пакетных менеджерах Nix, Lix и Guix" +/–

Сообщение от Amerigo (?), 25-Июн-25, 14:26

Flakes + Overlays вам в помощь.

Ответить | Правка | Наверх | Cообщить модератору

20. "Уязвимости в пакетных менеджерах Nix, Lix и Guix" +/–

Сообщение от Аноним (4), 25-Июн-25, 14:55

Быстро просмотрел. Но, кажется, там нет возможности задать использование разных версий библиотек в разных комбинациях.

Ответить | Правка | Наверх | Cообщить модератору

23. "Уязвимости в пакетных менеджерах Nix, Lix и Guix" +/–

Сообщение от Аноним (17), 25-Июн-25, 15:06

> все используемые библиотеки всех версий
Это ж сколько там будет версий! Попробуй взять калькулятор и рассчитать, сколько миллиардов сборок тебе придется сделать.

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

31. "Уязвимости в пакетных менеджерах Nix, Lix и Guix" +/–

Сообщение от Аноним (61), 25-Июн-25, 15:36

>Типа написал один конфиг сборки - и генерируешь пакеты своей программы на каждую комбинацию библиотек.
Можно, map reduce изобретён. Ну разумеется, если исходный код и компилятор такое переживёт, со стороны nix таких ограничений нет. Всё же nix это функциональный язык.

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

37. "Уязвимости в пакетных менеджерах Nix, Lix и Guix" +1 +/–

Сообщение от Аноним (17), 25-Июн-25, 15:48

А вообще, в никсе так не принято. (Да и нигде так не принято.) Ты оформляешь пакет в виде функции, которая: 1) принимает все свои зависимости во входном attrset, 2) возвращает дериватив. Далее этот пакет вызываешь при помощи pkgs.callPackage. И все, финальный пакет соберется с зависимостями, подтянутыми из pkgs. Но если кому-то приспичило подменить одну зависимость на другую, он сделает your-package.override { libfoo = libfoo-123; }. Пытаться сразу собирать пакет со всеми возможными комбинациями действительно приведет к миллиардам сборок: месяцами будешь тестировать 24/7 и платить за электричество.

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

41. "Уязвимости в пакетных менеджерах Nix, Lix и Guix" +/–

Сообщение от Аноним (61), 25-Июн-25, 16:03

>А вообще, в никсе так не принято. (Да и нигде так не принято.)
Не совсем. Вот есть, например pkgs.pkgsMusl, который хранит в себе дерево пакетов для musl. Или есть pkgs.linuxPackages, который позволяет как выбрать версию ядра, так и сразу какой-то набор патчей. Так что уже прямо в репозитории есть готовые пакеты несколькоих разных версий.

Ответить | Правка | Наверх | Cообщить модератору

57. "Уязвимости в пакетных менеджерах Nix, Lix и Guix" +/–

Сообщение от Аноним (57), 25-Июн-25, 22:57

> Пытаться сразу собирать пакет со всеми возможными комбинациями действительно приведет к миллиардам сборок: месяцами будешь тестировать 24/7 и платить за электричество.
Очевидно это в общем случае.
В частном - у меня используется, скажем, 5 библиотек для которых выпускают версии раз в год - два.
В итоге сборок будет много - но не бесконечно много.

Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

5. "Уязвимости в пакетных менеджерах Nix, Lix и Guix" +2 +/–

Сообщение от Аноним (-), 25-Июн-25, 14:11

Это тот самый NIX который используется в самой лучшей (по мнению её фанатов) NixOS ?
Которая самая удобная и безопасная, не то что ваши эти...

Ответить | Правка | Наверх | Cообщить модератору

7. "Уязвимости в пакетных менеджерах Nix, Lix и Guix" +/–

Сообщение от Аноним (-), 25-Июн-25, 14:14

Ага.

Ответить | Правка | Наверх | Cообщить модератору

9. "Уязвимости в пакетных менеджерах Nix, Lix и Guix" +/–

Сообщение от Аноним (9), 25-Июн-25, 14:19

Что же безопасно...

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

15. "Уязвимости в пакетных менеджерах Nix, Lix и Guix" +3 +/–

Сообщение от Шарп (ok), 25-Июн-25, 14:40

Лабораторная уязвимость. В реальности недостижимо.

Ответить | Правка | Наверх | Cообщить модератору

22. "Уязвимости в пакетных менеджерах Nix, Lix и Guix" +/–

Сообщение от Аноним (4), 25-Июн-25, 14:58

Вообще-то стандартная. Делаешь свою сборку пытающуюся использовать эту уязвимость. 100000 соберут - у одного сработает. Все - профит.

Ответить | Правка | Наверх | Cообщить модератору

24. "Уязвимости в пакетных менеджерах Nix, Lix и Guix" +/–

Сообщение от User (??), 25-Июн-25, 15:12

Поди што и чинить не надо?
Хотя... не rhel с ubuntu'ой - на той машине с NIX'ом один черт, ничего интересного нет, а те 5 сольдо что есть - проще выцыганить звонком про "безопасный счет ФСБ"...

Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

46. "Уязвимости в пакетных менеджерах Nix, Lix и Guix" +/–

Сообщение от Аноним (46), 25-Июн-25, 17:46

Не доверяю я всем этим никсам. Раздражает все это жуткое дробление, каждый норовит придумать свою систему сборки, свой линукс, свой язык. Думает, что лучше других знает как надо программировать.
А простве работяги от этого страдают, захламляют свои системы всяким барахлом, нужным для одного конкретного пакета.
Думаю, что nih синдром пора классифицировать как реальное заболевание и принудительно лечить на рабочих местах(и организовать патрули в местах проживания/скопления программистов)

Ответить | Правка | Наверх | Cообщить модератору

47. "Уязвимости в пакетных менеджерах Nix, Lix и Guix" +2 +/–

Сообщение от аноним1277zx (?), 25-Июн-25, 18:01

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

Ответить | Правка | Наверх | Cообщить модератору

53. "Уязвимости в пакетных менеджерах Nix, Lix и Guix" –1 +/–

Сообщение от Аноним (61), 25-Июн-25, 21:14

Типичный вахтёр - сам ничего не делает, а другим запрещает. Осуждаю.

Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+3 +/–
Сообщение от IMBird (ok), 25-Июн-25, 14:03
Эти уязвимости кого надо уязвимости. Нужно больше дистрибутивов и больше систем, чтобы никто адекватный об аудите даже не задумывался. Пакетные системы BSD и гайки всё ещё самые адекватные по реализации.
Ответить \| Правка \| Наверх \| Cообщить модератору


	10. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от bOOster (ok), 25-Июн-25, 14:21
	И в целом там и о расте адекватно задумываются - как о возможности, а не панацее..
	Ответить \| Правка \| Наверх \| Cообщить модератору


	18. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	–1 +/–
	Сообщение от Аноним (-), 25-Июн-25, 14:50
	Исходный код раст открыт? Как он с GNU уживётся? Если проприетарный раст будет использоваться, то GNU уже будет не торт. Весь смысл потеряется. Люди тогда прежде чем покупать устройство под PureOS, могут и задуматься - а зачем? Устройства Librem не такие уж и дешевые как кажутся: https://puri.sm/products/
	Ответить \| Правка \| Наверх \| Cообщить модератору


	12. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+1 +/–
	Сообщение от Аноним (12), 25-Июн-25, 14:28
	>Пакетные системы BSD и гайки всё ещё самые адекватные по реализации. И самые неуловимые, как Джо.
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	35. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (35), 25-Июн-25, 15:45
	Это раньше было что Джо неуловимый потому что никому не нужен. По текущим нормам корпорации за информацию сколько любой самый ненужный Джо с дивана вставал уже давятся.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	16. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (-), 25-Июн-25, 14:44
	Больше пакетных менеджеров и пакетов, пакетов, пакетов!
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	19. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (19), 25-Июн-25, 14:50
	>Пакетные системы BSD и гайки всё ещё самые адекватные по реализации. В FreeBSD до недавнего времени скачивание и сборка производились под рутом, без какого-либо ограничения доступа к системе.
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	43. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (43), 25-Июн-25, 16:44
	> В FreeBSD до недавнего времени скачивание и сборка производились под рутом, без какого-либо ограничения доступа к системе. Главное, не забывать повторять услышанное в перепеве Рабиновича (кстати, "сборка" чего? pkg ничего не собирает) commit c239d131dc920d6f3dead18a8e9a772372fe9578 Author: Bryan Drewery <bryan@shatow.net> Date: Wed Jan 31 15:53:19 2018 -0800 audit: Drop privileges after opening the files/database but before parsing. commit f3b0469eb8669967d76d18fb56222853ca30871d Author: Baptiste Daroussin <bapt@FreeBSD.org> Date: Fri Nov 11 22:18:25 2016 +0100 Stop dropping privileges when fetching as it causes more issues than it solved commit fcceab3f1e0ae780e8a91918488aab3ba5f5ea1c Author: Baptiste Daroussin <bapt@FreeBSD.org> Date: Sat Aug 20 01:17:34 2016 +0200 drop privileges when using libfetch Вот еще немного "на закуску" pkg_repo.c /* * We need to load this pubkey from meta / if (pkg_emit_sandbox_get_string(pkg_repo_meta_extract_pubkey, &cbdata pkg_sandbox.c int pkg_handle_sandboxed_get_string(pkg_sandbox_cb func, char result, int64_t len, void ud) ... / Here comes child process / close(pair[1]); pkg_drop_privileges(); rl_zero.rlim_cur = rl_zero.rlim_max = 0; if (setrlimit(RLIMIT_NPROC, &rl_zero) == -1) err(EXIT_FAILURE, "Unable to setrlimit(RLIMIT_NPROC)"); #ifdef HAVE_CAPSICUM #ifndef PKG_COVERAGE if (cap_enter() < 0 && errno != ENOSYS) { void pkg_drop_privileges(void) { struct passwd nobody; if (geteuid() == 0) { nobody = getpwnam("nobody"); if (nobody == NULL) errx(EXIT_FAILURE, "Unable to drop privileges: no 'nobody' user"); setgroups(1, &nobody->pw_gid);
	Ответить \| Правка \| Наверх \| Cообщить модератору


	61. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	–1 +/–
	Сообщение от Аноним (61), 26-Июн-25, 00:36
	>Главное, не забывать повторять услышанное в перепеве Рабиновича Вам же хорошо сказано >до недавнего времени Посмотрите на дату коммита >2018, 2016 Когда там bsd появилась, в каком году? Солько лет так жили - 10, 20, а то может и все 40?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	55. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (55), 25-Июн-25, 22:36
	Всю жизнь рут требовался только для make install.
	Ответить \| Правка \| К родителю #19 \| Наверх \| Cообщить модератору


	32. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	–5 +/–
	Сообщение от Аноним (61), 25-Июн-25, 15:38
	>Пакетные системы BSD и гайки всё ещё самые адекватные по реализации. Топорные топоры из каменного века, не способные почти ни на что?
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	36. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+2 +/–
	Сообщение от Аноним (35), 25-Июн-25, 15:48
	Иногда топоры покрайней мере надёжные, а все новомодные пукалки не вызывают доверия.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	40. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	–3 +/–
	Сообщение от Аноним (61), 25-Июн-25, 15:56
	Я надеюсь, что еду себе вы готовите на костре, дрова для которого, срублены каменным топором. Мангал, печь и другихе хипсторские смузитехнологии не используете.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	44. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Голум (?), 25-Июн-25, 17:07
	Они у вас лишь иногда надёжные? А всё остальное время тоже не вызывают доверия?
	Ответить \| Правка \| К родителю #36 \| Наверх \| Cообщить модератору

2. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+9 +/–
Сообщение от Анонимище (?), 25-Июн-25, 14:04
Какие созвучные имена пакетных менеджеров, прямо как из сказки про трех поросят
Ответить \| Правка \| Наверх \| Cообщить модератору


	33. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Кошкажена (?), 25-Июн-25, 15:38
	> Какие созвучные имена пакетных менеджеров, прямо как из сказки про трех поросят Я злой и страшный серый волк, я в поросятах^Wпакетных менеджерах знаю толк!
	Ответить \| Правка \| Наверх \| Cообщить модератору

3. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+4 +/–
Сообщение от Fracta1L (ok), 25-Июн-25, 14:08
Фоновые процессы для установки программ, вот это клиника
Ответить \| Правка \| Наверх \| Cообщить модератору


	8. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	–1 +/–
	Сообщение от Аноним (-), 25-Июн-25, 14:14
	Почему?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	17. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+1 +/–
	Сообщение от Аноним (17), 25-Июн-25, 14:49
	Фоновые процессы для монтирования/размонтирования, для вывода звука, для вывода окошек, для показа диалога "Открыть файл", для отправки сообщения в третий процесс через шину, для всего подряд. А ты тут про какую-то установку программ.
	Ответить \| Правка \| К родителю #3 \| Наверх \| Cообщить модератору


	26. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+1 +/–
	Сообщение от Fracta1L (ok), 25-Июн-25, 15:17
	Это всё можно понять, потому что для нормальной комфортной работы этих подсистем нужно ловить события. А какие к чёрту события могут быть у менеджера пакетов, что это потребовало демона?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	27. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от 12yoexpert (ok), 25-Июн-25, 15:24
	в унбунте до сих пор нельзя выключить попапы обновлений без rm -rf что-то-там?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	29. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (17), 25-Июн-25, 15:25
	Событие "собери/скачай такой-то дериватив". Это позволяет обычным пользователям пользоваться услугами сборщика. Почему так сделано? Ответ в твоем комменте: "для нормальной комфортной работы".
	Ответить \| Правка \| К родителю #26 \| Наверх \| Cообщить модератору


	34. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+2 +/–
	Сообщение от Аноним (61), 25-Июн-25, 15:44
	>А какие к чёрту события могут быть у менеджера пакетов, что это потребовало демона? Сразу видно ыксперда. Событие - пользователь инициировал сборку чего-то там. Далее, от непривилегированного пользователя запускается скачиваение и сборка всего этого дела в чистом окружении. Добавим сюда тот факт, что это системный пакетный менеджер, который кеширует результаты сборок, делая их разделяемыми для всей системы целиком, а не только для текущего проекта, удаляет ставшие ненужными пакеты, занимается перезапуском различных служб и так далее.
	Ответить \| Правка \| К родителю #26 \| Наверх \| Cообщить модератору


	48. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (48), 25-Июн-25, 19:22
	> и так далее и для этого всего нужен демон? это же обычный сценарий, который можно и по крону запустить, демон зачем?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	52. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (61), 25-Июн-25, 21:11
	>это же обычный сценарий, который можно и по крону запустить А крон давно демоном быть перестал? >который можно и по крону запустить Когда я вызываю nix, то хочу получить результат сразу же, а не в следующий день. Минимальное разрешение крона - минута. Далее, у вас будет задача вернуть результат из крона именно той программе, которая его вызвала, поскольку в NixOS nix может вызываться достаточно часто. >демон зачем? Для обработки запросов пользователя. Это точно так же, как условный nginx - вы отправляете запрос, его прямо сейчас обрабатывают и выдают ответ. Работа с пакетами происходит в изолированном окружении, исходники вначале скачиваются, а потом уже без интернета собираются. Это уже тянет как минимум на условный подман. В условном дебине или арче исходник может во-первых выкачать бекдор прямо в момент сборки, во-вторых, там нет никакой проверки описания пакета, например, можно забыть, что пакету нужен gcc, и если gcc уже стоит в системе, то пакет молча соберётся, но его спецификация будет неверной. это одна из причин, по какой для сборки рекомендуют создавать отдельное окружение. Далее, добавим тот факт, что это системный пакетный менеджер. У условного подмана практически нет кеширования образов. Незначительные изменения докерфайла, и всё будет перекачиваться/пересобираться повторно. Условные bash будет в каждом образе качаться независимо друг от друга. Далее, возьмём удаление пакетов: привычного apt remove в nix нет, поскольку пакеты не ставятся глобально. Вместо этого применяется стратегия со сборкой мусора - есть несколько корней, которые рекурсивно удерживают пакеты от удаления. Как следствие, во время сборки мусора нужно точно знать, какие пакеты используются прямо сейчас, а какие - нет. Есть текущая сборка, есть предыдущие, на которые пользователь может откатится простой перезагрузкой, есть systemd контейнеры, есть анонимные окружения, запущенные через nix-shell -p, есть окружения запущенные через nix файлы. Всё это дело и удерживает пакеты в системе. Условный apt в убунте намертво блокируется, если фоном выполняется какая-то операция, например проверяется наличие обновлений, так как может выполняться только один экземпляр apt, в противном случае один apt поставит пакет с зависимостью о libfoo, а второй эту зависимость снесёт как ставшую ненужной. Подману абсолютно всё равно, сколько libfoo у вас есть, для исправления этого даже специальные файловые системы изобретают.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	58. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (48), 25-Июн-25, 23:06
	> А крон давно демоном быть перестал? так для него это необходимость, один демон, исполняющий периодически необходимые сценарии, а не на каждый чих свой демон. > Когда я вызываю nix, то хочу получить результат сразу же, а не в следующий день. ну а демон зачем вам, если вы просто запускаете сценарий? Крон это пример где демон - необходимость, когда необходимо периодически запускать сценарии. > Для обработки запросов пользователя. понятие "интерактивная программа" незнакома? > Это точно так же, как условный nginx - вы отправляете запрос, его прямо сейчас обрабатывают и выдают ответ. любая вызванная команда выполняется прямо сейчас и выдает ответ. Nginx - служба по определению, так как работает 24 на 7. В установке (сборке) софта нет необходимости службы 24 на 7. Почему у вас калькулятор еще не служба или там текстовый редактор? > Работа с пакетами происходит в изолированном окружении, исходники вначале скачиваются, а потом уже без интернета собираются. неважно как там все это происходит, тут главное что это происходит по действию пользователя при необходимости, и необходимости в 24 на 7 нет. > это одна из причин, по какой для сборки рекомендуют создавать отдельное окружение вы лучше про причину необходимости демона напишите
	Ответить \| Правка \| Наверх \| Cообщить модератору


	59. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (61), 26-Июн-25, 00:27
	>а не на каждый чих свой демон. Количество демонов с начала 70-ых возросло. Очень сильно. Тот же snap из убунты, например. >ну а демон зачем вам, если вы просто запускаете сценарий? Затем, что кто-то должен слушать /nix/var/nix/daemon-socket/socket. >понятие "интерактивная программа" незнакома? Очень много интерактивных программ живёт с демонами. Как тот же докер. Как pulseaudio, pipewire. Уже вам четыре программы в одном сообщении, но суммарно их гораздо больше. >любая вызванная команда выполняется прямо сейчас и выдает ответ. Не любая. Для СУБД существует клиент и сервер, даже если база запущена на одном устройстве. Существуют исключения, игрушечные СУБД типа sqlite, но именно исключения. >В установке (сборке) софта нет необходимости службы 24 на 7. Вы глубоко неправы. Демон нужен не для 24 на 7, а как единая точка входа, обрабатывающая все запросы. Как условный xorg, wayland композитор, pulseaudio, systemd, да даже minecraft, или условный python -m http.server. Это в дебиане/арче софт ставится разово, или не ставится вообще, так как поставить две версии libfoo без танца с бубнами нельзя, и на этом история заканчивается. Как там было в комиксе xkcd, про ноутбук зону отчуждения, на котором куча установок python. В NixOS даже для установленного софта нужен nix, например для компиляции. И каждый раз, когда нужно запустить компиляцию, вы заходите в каталог с проектом и разворачиваете окружение. Ибо одному проекту нужна libfoo 0.5 версии, а второму - 2. Более того, в некоторых случаях nix может идти в самом начале shebang-а - у вас каждый запуск софта будет запускаться nix. >неважно как там все это происходит Как раз таки важно. Вы до сих пор не привели ни одного примера, как достичь аналогичного функционала без демона. Ни по воспроизводимой сборке, ни по безопасной сборке, ни по сохраниению целосности системы, ни по удобству использования, ни по лени, ни по кешированию. Уже этих свойств более чем достаточно. >и необходимости в 24 на 7 нет. Вы вначале придумали аргумент 24/7, и теперь его повторяете. >вы лучше про причину необходимости демона напишите Вам уже написали кучу причин, но вы притворяетесь что их нет.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	63. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (48), 26-Июн-25, 01:01
	> Количество демонов с начала 70-ых возросло. Очень сильно. Тот же snap из убунты, например. Дайте определение понятия демон (служба), я думаю вы не понимаете значение этого термина. > Очень много интерактивных программ живёт с демонами. Как тот же докер. Как pulseaudio, pipewire. Уже вам четыре программы в одном сообщении, но суммарно их гораздо больше. Я не вижу в этом списке ни калькулятора, не текстового редактора, ни сапера (игра), но вероятно в этом списке явно должен быть виджет погоды или температуры процессора. Так в чем дело? > Не любая. Для СУБД существует клиент и сервер, даже если база запущена на одном устройстве. Ну существует, и что мы не запускаем клиент? Мы не получаем интерактивного приглашение? В чем дело? А сервер СУБД - служба, и служит она не только мне по определению службы. А клиент - это интерактивная программа запускаемая при необходимости, почему у вас клиент не служба? > Вы глубоко неправы. Демон нужен не для 24 на 7, а как единая точка входа, обрабатывающая все запросы. У вас шо там другого способа меж-процессного взаимодействия не нашлось? Правильно говорит Fracta1L - это клиника. > Как условный xorg, wayland композитор, pulseaudio, systemd, да даже minecraft, или условный python -m http.server. Почему в этом списке нет калькулятора? > Вы до сих пор не привели ни одного примера, как достичь аналогичного функционала без демона. Когда поймете для чего необходимы демоны, тогда поймете как достичь. > Уже этих свойств более чем достаточно. Ей ГНУ-шники, почему ваш gcc до сих пор не демон? Вы можете не отвечать, вопрос не вам. > Вы вначале придумали аргумент 24/7, и теперь его повторяете. Потому-что до вас элементарно не доходит значение слова демон (служба) > Вам уже написали кучу причин, но вы притворяетесь что их нет. Отправьте эти причины ГНУ-шникам, чтобы в следующей версии gcc был демоном.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	67. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (17), 26-Июн-25, 03:23
	> другого способа меж-процессного взаимодействия не нашлось? Если есть меж-процессное взаимодействие, значит процессов как минимум два. На этом коммент можно завершать, так как ты уже сам постулируешь необходимость демона (второй процесс из двух). Но продолжим: "Другой способ меж-процессного взаимодействия" -- это активация по требованию. И он требует демон, который будет активировать другого демона: 1. Прога А обращается к шине (демону d-bus) с просьбой активировать прогу Б. 2. Демон активирует (запускает) прогу Б. 3. Прога Б регистрируется в шине d-bus в качестве демона, отвечающего на запросы. 4. Прога А и прога Б (два процесса) общаются меж собой через шину (через демон d-bus, третий процесс). Как видишь, альтернатива двум процессам -- это три процесса. Рассмотрим другой случай: прога А запускает напрямую прогу Б без всяких демонов. В этом случае прога Б будет иметь те же права, что и прога А, а значит уже не сможет запускать билдеров, напрямую записывать в /nix/store результаты и выполнять прочие вещи, необходимые с точки зрения nix. Поэтому прогу А придется запускать из-под рута. Это неудобный вариант. При желании, можно отказаться от демона nix, там это именуется "single-user mode" https://nix.dev/manual/nix/2.24/installation/nix-security -- со всеми вытекающими ограничениями. В NixOS правда никто так не делает: иметь демона тупо удобно, а без демона тупо неудобно. Когда я запускаю VSCode, и в нем поднимается окружение из flake.nix + direnv, я не хочу вводить рутовый пароль, чтоб скачать/собрать зависимости моего проекта. Спасибо демону, который слушает мои просьбы собрать/скачать зависимости и делает все необходимое с рутовыми правами, которые у него есть (а у меня нет на момент запуска VSCode).
	Ответить \| Правка \| Наверх \| Cообщить модератору


	68. "Уязвимости в пакетных менеджерах Nix, Lix и Guix"	+/–
	Сообщение от Аноним (68), 26-Июн-25, 08:30
	> Вы до сих пор не привели ни одного примера, как достичь аналогичного функционала без демона. Ни по воспроизводимой сборке, ни по безопасной сборке, ни по сохраниению целосности системы, ни по удобству использования, ни по лени, ни по кешированию. Уже этих свойств более чем достаточно. > И каждый раз, когда нужно запустить компиляцию, вы заходите в каталог с проектом и разворачиваете окружение. Вы сами на свои вопросы и отвечаете, нет? Делаете окружение пользователя-сборщика пакетов, компилируете пакет с указыванием нужного ABI (а не libчто-то.so), собираете в тарбол и файликом, который говорит, какой конкретно ABI мы хотим. Вы проблему версий "одному нужно то, другому это" из пальца высасываете банальным нежеланием напрямую пользоваться инструментами, которые у вас в линуксе уже есть.
	Ответить \| Правка \| К родителю #59 \| Наверх \| Cообщить модератору