48431 2023-11-14 07:13:12 +0300 Позволяет установить любой пакет пользователю из группы wheel без пароля 2025-07-21 22:23:19 +0300 1 1 4 Development Sisyphus packagekit unstable all Linux CLOSED FIXED https://bugzilla.altlinux.org/show_bug.cgi?id=35763 P5 normal --- 46625 1 antohami sirius aen imz iv ldv mr.shad nbr rider shrek sin sirius snowmix zerg qa-sisyphus oldest_to_newest 237006 0 antohami 2023-11-14 07:13:12 +0300 packagekit позволяет установить любой пакет пользователю из группы wheel без пароля: pkcon install любой_пакет Предлагаю вынести в отдельный пакет polkit правило /usr/share/polkit-1/rules.d/org.freedesktop.packagekit.rules, которое за это отвечает. Пусть добавление этого правила в дистрибутив будет на совести релиз-менеджера этого дистрибутива или администратора, установившего этот пакет. 237009 1 rider 2023-11-14 08:50:07 +0300 пользователь в группе wheel имеет и так слишком много привилегий, не надо усложнять жизнь. 237012 2 aen 2023-11-14 09:02:02 +0300 (Ответ для Anton Farygin на комментарий #1) > пользователь в группе wheel имеет и так слишком много привилегий, не надо > усложнять жизнь. antohami@ предлагает не исключать этот вариант, а оставить его на усмотрение релиз-менеджера. И предлагает простое решение. WONTFIX не про это. 237013 3 zerg 2023-11-14 09:09:57 +0300 Так и задумано. Устанавливать может, а удалять -- фигу. 237018 4 antohami 2023-11-14 09:26:59 +0300 (Ответ для Sergey V Turchin на комментарий #3) > Так и задумано. Устанавливать может, а удалять -- фигу. Ладно. Я у себя это недоразумение исправлю. Выкрутить правило обратно не проблема: https://bugzilla.altlinux.org/show_bug.cgi?id=41895#c3 237020 5 ldv 2023-11-14 09:41:15 +0300 Просьба ещё раз прочитать и прислушаться к тому, что написал Антон. 237022 6 zerg 2023-11-14 09:50:35 +0300 (Ответ для Антон Мидюков на комментарий #4) > Ладно. Я у себя это недоразумение исправлю. Выкрутить правило обратно не > проблема: > https://bugzilla.altlinux.org/show_bug.cgi?id=41895#c3 Это совсем не понял. У меня и такой packagekit и polkit-rule-admin-root. Выкручивание чего именно и что именно может исправить? 237023 7 zerg 2023-11-14 09:54:42 +0300 (Ответ для Dmitry V. Levin на комментарий #5) > Просьба ещё раз прочитать и прислушаться к тому, что написал Антон. Где взять синтезатор голоса Антона. ;-) 237024 8 antohami 2023-11-14 09:55:46 +0300 (Ответ для Sergey V Turchin на комментарий #6) > (Ответ для Антон Мидюков на комментарий #4) > > Ладно. Я у себя это недоразумение исправлю. Выкрутить правило обратно не > > проблема: > > https://bugzilla.altlinux.org/show_bug.cgi?id=41895#c3 > Это совсем не понял. > У меня и такой packagekit и polkit-rule-admin-root. Выкручивание чего именно > и что именно может исправить? Сделаю аналогичный пакет polkit-rule-packagekit-disallow-install, где будет такое: cat>%buildroot/%_datadir/polkit-1/rules.d/40-packagekit-disallow-install.rules<<EOF polkit.addRule(function(action, subject) { if (action.id == "org.freedesktop.packagekit.package-install" && subject.active == true && subject.local == true && subject.isInGroup("wheel")) { return polkit.Result.AUTH_ADMIN; } }); EOF Будет пароль админа спрашивать. Но бага изначально о том, что умолчание не должно быть разрешающим. Кто хочет разрешить, устанавливает пакет с разрешающим правилом. А вы вынуждаете делать наоборот. Писать запрещающие правила, так как дефолт разрешающий. 237025 9 zerg 2023-11-14 10:02:28 +0300 В принципе, я не против отдельного пакета. Только, это должно быть совместимо с p10, т.е. не отвалится никакая сборка и ни установка пакетов ни в одном из бранчей и ни в одной из программ, использующих packagekit. 237026 10 rider 2023-11-14 10:06:17 +0300 (Ответ для AEN на комментарий #2) > (Ответ для Anton Farygin на комментарий #1) > > пользователь в группе wheel имеет и так слишком много привилегий, не надо > > усложнять жизнь. > > antohami@ предлагает не исключать этот вариант, а оставить его на усмотрение > релиз-менеджера. > И предлагает простое решение. WONTFIX не про это. Нет, сейчас умолчания правильные, не надо их оставлять на усмотрение релиз-менеджера. 237027 11 zerg 2023-11-14 10:08:11 +0300 (Ответ для Антон Мидюков на комментарий #8) > Но бага изначально о том, что умолчание не должно быть разрешающим. Кто > хочет разрешить, устанавливает пакет с разрешающим правилом. А вы вынуждаете > делать наоборот. Писать запрещающие правила, так как дефолт разрешающий. С этим можно поспорить. У нас много чего разрешено по умолчанию так или иначе. P.S. Или, наоборот, пример "правильного поведения". Попробуйте на регулярке простого пользователя заставить включить возможность расшаривать пользовательские каталоги по samba, причём сделать это правильно. Он скорее повесится. 237028 12 aen 2023-11-14 10:11:44 +0300 (Ответ для Sergey V Turchin на комментарий #11) > (Ответ для Антон Мидюков на комментарий #8) > > Но бага изначально о том, что умолчание не должно быть разрешающим. Кто > > хочет разрешить, устанавливает пакет с разрешающим правилом. А вы вынуждаете > > делать наоборот. Писать запрещающие правила, так как дефолт разрешающий. > С этим можно поспорить. У нас много чего разрешено по умолчанию так или > иначе. > > P.S. > Или, наоборот, пример "правильного поведения". Попробуйте на регулярке > простого пользователя заставить включить возможность расшаривать > пользовательские каталоги по samba, причём сделать это правильно. Он скорее > повесится. Регулярки не для простого пользователя. Некорректный пример. 237029 13 rider 2023-11-14 10:12:38 +0300 Поясню для истории: пользователь в группе wheel имеет повышенные привилегии в системы - в большинстве конфигураций он может делать многие гораздо более серьёзные вещи, чем ставить пакеты через packagekit. Если релиз-менеджер не доверяет пользователю, то не надо его включать в группу wheel. 237030 14 zerg 2023-11-14 10:14:24 +0300 (Ответ для AEN на комментарий #12) > Регулярки не для простого пользователя. Некорректный пример. А вы сами попробуйте. ;-) 237031 15 rider 2023-11-14 10:18:27 +0300 Возможно, было бы неплохо ввести дополнительную группу с правами обновления системы и установки пакетов. И так же по умолчанию включать в неё первого пользователя системы (и сделать интерфейс для настройки привилегий - каким пользователям какие действия можно осуществлять). Но wheel тут точно не виноват, не надо его трогать (и ломать существующее поведение). 237032 16 aen 2023-11-14 10:18:53 +0300 (Ответ для Sergey V Turchin на комментарий #14) > (Ответ для AEN на комментарий #12) > > Регулярки не для простого пользователя. Некорректный пример. > А вы сами попробуйте. ;-) Спасибо, но я это делал. 237034 17 rider 2023-11-14 10:19:50 +0300 Алексей, ты точно не пробовал расшаривать папку через samba на регулярке. Не флудите, пожалуйста. 237035 18 zerg 2023-11-14 10:21:12 +0300 (Ответ для AEN на комментарий #16) > Спасибо, но я это делал. Нет. ;-) https://www.altlinux.org/Samba/Usershares 237037 19 zerg 2023-11-14 10:23:12 +0300 (Ответ для Anton Farygin на комментарий #15) > Возможно, было бы неплохо ввести дополнительную группу с правами обновления > системы и установки пакетов. IMHO уже лучше правила polkit изменить, только так, чтоб никому не испортить. 237040 20 aen 2023-11-14 10:28:49 +0300 (Ответ для Anton Farygin на комментарий #17) > Алексей, ты точно не пробовал расшаривать папку через samba на регулярке. > Не флудите, пожалуйста. Никакого флуда. Года два назад делал, установив пакеты. 237041 21 zerg 2023-11-14 10:41:57 +0300 (Ответ для AEN на комментарий #12) > Регулярки не для простого пользователя. Некорректный пример. Ок, вот корректный: простой пользователь устанавливает К-10.0, обновляется, после чего пытается восстановить сломанное расшаривание по инструкции https://www.altlinux.org/Samba/Usershares 237081 22 ldv 2023-11-14 14:58:33 +0300 (In reply to Anton Farygin from comment #10) > Нет, сейчас умолчания правильные, не надо их оставлять на усмотрение > релиз-менеджера. На самом деле нет. (In reply to Sergey V Turchin from comment #11) > (Ответ для Антон Мидюков на комментарий #8) > > Но бага изначально о том, что умолчание не должно быть разрешающим. Кто > > хочет разрешить, устанавливает пакет с разрешающим правилом. А вы вынуждаете > > делать наоборот. Писать запрещающие правила, так как дефолт разрешающий. > С этим можно поспорить. У нас много чего разрешено по умолчанию так или > иначе. Аргумент, будто мы не будем считать за баги некое поведение, потому что у нас якобы есть много аналогичных багов, которые ещё не исправлены, на мой взгляд, должен убеждать в обратном. 237087 23 zerg 2023-11-14 15:30:05 +0300 (Ответ для Dmitry V. Levin на комментарий #22) > якобы Только эти "якобы" и "пока" там не мои. Ну и мою позицию я определил в comment#9. 237092 24 rider 2023-11-14 15:55:31 +0300 Ну так это же просто - эти "баги" на самом деле очень хорошие фичи. И обсуждаемая здесь относится к их числу. Ну или ошибка (FR) должна звучать каким-то другим образом. 237100 25 aen 2023-11-14 18:08:48 +0300 Я не увидел содержательных аргументов против предложения Антона, только стремлениее закрыть багу и обсуждение. 237103 26 antohami 2023-11-14 18:28:40 +0300 Прошу ответить на вопрос: Зачем понадобилось разрешать установку пакетов без ввода пароля? 237104 27 rider 2023-11-14 18:31:04 +0300 Для того, что бы пользователь из группы wheel мог делать это без ввода пароля. 237105 28 antohami 2023-11-14 18:34:43 +0300 (Ответ для Anton Farygin на комментарий #27) > Для того, что бы пользователь из группы wheel мог делать это без ввода > пароля. Под "это" скрывается только "установка произвольных пакетов" или что-то ещё? 237106 29 rider 2023-11-14 18:43:36 +0300 Стандартный сценарий - установка/доустановка пакетов и обновление системы. 237107 30 aen 2023-11-14 18:58:14 +0300 (Ответ для Anton Farygin на комментарий #29) > Стандартный сценарий - установка/доустановка пакетов и обновление системы. Что это за "стандарт"? Безопасностью нашей системы занимался ldv@. Есть требования ФСТЭК. Давайте все же разберемся. Хотелось бы услышать Диму и Дениса (подключаю его). 237109 31 ldv 2023-11-14 19:04:52 +0300 Группа wheel была задумана не как замена root, а как группа, членам которой может быть позволено авторизоваться для выполнения тех или иных привилегированных операций. Тот факт, что кому-то показалось удобным не спрашивать у членов группы wheel authentication tokens и сразу давать привилегированный доступ, не значит, что это хорошее поведение по-умолчанию, и тем более не значит, что позволено пытаться запрещать поведение, которое другие считают более правильным и подходящим для решаемых задач. Это валидный багрепорт, поэтому, пожалуйста, не надо его закрывать как NOTABUG. 237110 32 antohami 2023-11-14 19:10:02 +0300 (Ответ для Anton Farygin на комментарий #29) > Стандартный сценарий - установка/доустановка пакетов и обновление системы. Мои эксперименты показали, что обновиться можно без этого правила, так как обновляет сервис packagekit-offline-update.service после перезагрузки. Подготовить обновление может пользователь без ввода пароля через discover или gnome-software, нажав соответствующую кнопочку. Т.е. для обновления системы это правило не нужно. 237112 33 rider 2023-11-14 19:34:22 +0300 (Ответ для AEN на комментарий #30) > (Ответ для Anton Farygin на комментарий #29) > > Стандартный сценарий - установка/доустановка пакетов и обновление системы. > > Что это за "стандарт"? Безопасностью нашей системы занимался ldv@. Есть > требования ФСТЭК. > Давайте все же разберемся. Хотелось бы услышать Диму и Дениса (подключаю > его). ФСТЭК то тут при чём ? Там обновления идут вообще по другому пути и packagekit не используется. Этот багрепорт не валиден, т.к. нет никакой ошибки, не нарушены никакие правила и требования - нигде нет формальных требований работать именно так а не иначе. Можете рассказать истинную причину появления этой ошибки ? 237113 34 antohami 2023-11-14 19:39:52 +0300 (Ответ для Anton Farygin на комментарий #33) > (Ответ для AEN на комментарий #30) > > (Ответ для Anton Farygin на комментарий #29) > > > Стандартный сценарий - установка/доустановка пакетов и обновление системы. > > > > Что это за "стандарт"? Безопасностью нашей системы занимался ldv@. Есть > > требования ФСТЭК. > > Давайте все же разберемся. Хотелось бы услышать Диму и Дениса (подключаю > > его). > > ФСТЭК то тут при чём ? Там обновления идут вообще по другому пути и > packagekit не используется. > > Этот багрепорт не валиден, т.к. нет никакой ошибки, не нарушены никакие > правила и требования - нигде нет формальных требований работать именно так а > не иначе. > > Можете рассказать истинную причину появления этой ошибки ? Я знакомился сегодня с packagekit. Был удивлён, отрапортовал. Не надо искать то, чего нет. 237114 35 rider 2023-11-14 19:42:35 +0300 А это поведение почему-то никого не беспокоит ? https://forum.altlinux.org/index.php?topic=41933.0 В общем если будет написана и согласована со всеми участниками единая политика безопасности, то и этот пакет будет ей следовать. 237115 36 ldv 2023-11-14 19:45:38 +0300 . 237116 37 aen 2023-11-14 19:47:21 +0300 (Ответ для Anton Farygin на комментарий #33) > (Ответ для AEN на комментарий #30) > > (Ответ для Anton Farygin на комментарий #29) > > > Стандартный сценарий - установка/доустановка пакетов и обновление системы. > > > > Что это за "стандарт"? Безопасностью нашей системы занимался ldv@. Есть > > требования ФСТЭК. > > Давайте все же разберемся. Хотелось бы услышать Диму и Дениса (подключаю > > его). > > ФСТЭК то тут при чём ? Там обновления идут вообще по другому пути и > packagekit не используется. > > Этот багрепорт не валиден, т.к. нет никакой ошибки, не нарушены никакие > правила и требования - нигде нет формальных требований работать именно так а > не иначе. Ты же сам писал про "стандартный сценарий". Где же стандарты? > > Можете рассказать истинную причину появления этой ошибки ? Всё описано Антоном. Забота о безопасности "из коробки". От тебя тоже нужны аргументы, не закрывать багу Дима уже просил. Давай говорить серьёзно и конструктивно, без конфликтов на ровном месте. Пожалуйста. 237117 38 ldv 2023-11-14 19:47:51 +0300 Пожалуйста, прекратите закрывать валидный багрепорт! 237118 39 aen 2023-11-14 19:49:21 +0300 (Ответ для Anton Farygin на комментарий #35) > А это поведение почему-то никого не беспокоит ? > https://forum.altlinux.org/index.php?topic=41933.0 > > В общем если будет написана и согласована со всеми участниками единая > политика безопасности, то и этот пакет будет ей следовать. Не надо ставить условия, пожалуйста. 237119 40 rider 2023-11-14 19:54:23 +0300 Дима, был бы валидный - я бы его не закрывал. Можем продолжать до бесконечности, но в любом случае прежде чем считать этот багрепорт валидным - надо описать условия использования, которые этот багрепорт нарушает. 237120 41 rider 2023-11-14 19:55:32 +0300 (Ответ для AEN на комментарий #39) > (Ответ для Anton Farygin на комментарий #35) > > А это поведение почему-то никого не беспокоит ? > > https://forum.altlinux.org/index.php?topic=41933.0 > > > > В общем если будет написана и согласована со всеми участниками единая > > политика безопасности, то и этот пакет будет ей следовать. > > Не надо ставить условия, пожалуйста. Это условия сосуществования разных взглядов на жизнь в одной экосистеме. 237121 42 aen 2023-11-14 20:00:59 +0300 (Ответ для Anton Farygin на комментарий #41) > (Ответ для AEN на комментарий #39) > > (Ответ для Anton Farygin на комментарий #35) > > > А это поведение почему-то никого не беспокоит ? > > > https://forum.altlinux.org/index.php?topic=41933.0 > > > > > > В общем если будет написана и согласована со всеми участниками единая > > > политика безопасности, то и этот пакет будет ей следовать. > > > > Не надо ставить условия, пожалуйста. > > Это условия сосуществования разных взглядов на жизнь в одной экосистеме. Условия сосуществования -- конструктивное обсуждение, а не закрытие обсуждаемой темы. Если взгляды разные, то тем более нельзя ставить условия. 237124 43 rider 2023-11-14 20:04:08 +0300 Пожалуйста, не надо переоткрывать - я не считаю это поведение ошибкой и буду считать только при появлении единого для всех систем документа, определяющего политику безопасности и в случае, если этот пакет будет нарушать ту самую политику безопасности. 237125 44 rider 2023-11-14 20:08:51 +0300 Я вам даже более того скажу - сейчас это поведение можно считать "стандартом" хотя бы из-за того, что другого поведения нет: # grep wheel /usr/share/polkit-1/rules.d/* /usr/share/polkit-1/rules.d/org.freedesktop.bolt.rules: subject.isInGroup("wheel")) { /usr/share/polkit-1/rules.d/org.freedesktop.Flatpak.rules: subject.isInGroup("wheel")) { /usr/share/polkit-1/rules.d/org.freedesktop.fwupd.rules: subject.isInGroup("wheel")) { /usr/share/polkit-1/rules.d/org.freedesktop.packagekit.rules: subject.isInGroup("wheel")) { Я же не просто так пишу что не надо придираться к packagekit без повода - давайте сделаем правила, договоримся о них и будем следовать. 237126 45 aen 2023-11-14 20:09:32 +0300 (Ответ для Anton Farygin на комментарий #43) > Пожалуйста, не надо переоткрывать - я не считаю это поведение ошибкой и буду > считать только при появлении единого для всех систем документа, > определяющего политику безопасности и в случае, если этот пакет будет > нарушать ту самую политику безопасности. Ты можешь считать как хочешь, но открывший багу считает иначе. Не надо тут командовать. Тем более что бага уже на nobody, а не на тебе. 237127 46 rider 2023-11-14 20:11:33 +0300 Алексей, давай не будем писать скрипт, который автоматом будет игнорировать тебя на всей багзилле. 237128 47 aen 2023-11-14 20:14:54 +0300 Напиши. Зачем тебе конфликт? 237130 48 rider 2023-11-14 20:18:57 +0300 Вот и я не понимаю что ты тут устраиваешь на ровном месте. у нас есть стандартный механизм утверждения политик упаковки пакетов в репозитории: https://www.altlinux.org/Policy_Policy Если кого-то не устраивает поведение по умолчанию пакетов, использующих мезанизм polkit для доступа к привелегиям в связке с wheel - он может написать Policy и предложить его на утверждение в devel. Я с удовольствием присоединюсь к этому обсуждению и уверен, что там и таким способом мы сможем выработать единый подход к решению обсуждаемой задачи. 237131 49 aen 2023-11-14 20:24:16 +0300 (Ответ для Anton Farygin на комментарий #48) > Вот и я не понимаю что ты тут устраиваешь на ровном месте. > > у нас есть стандартный механизм утверждения политик упаковки пакетов в > репозитории: > https://www.altlinux.org/Policy_Policy > > Если кого-то не устраивает поведение по умолчанию пакетов, использующих > мезанизм polkit для доступа к привелегиям в связке с wheel - он может > написать Policy и предложить его на утверждение в devel. > > Я с удовольствием присоединюсь к этому обсуждению и уверен, что там и таким > способом мы сможем выработать единый подход к решению обсуждаемой задачи. Предложение Антона нарушает Policy? 237132 50 rider 2023-11-14 20:32:16 +0300 предложение Антона меняет поведение по умолчанию несовместимым образом и отключает существующую фичу. Нужно веское основание для изменения поведения по умолчанию, к тому же такое поведение замечено за более чем одним пакетом (точнее - другого поведения у других использующих этот механизм - нет). Наличие принятого Policy будет веским основанием. 237133 51 ldv 2023-11-14 20:36:14 +0300 . 237135 52 ldv 2023-11-14 20:41:22 +0300 Я считаю, что багрепорт является валидным, и этого достаточно, чтобы он оставался открытым. 237136 53 rider 2023-11-14 20:42:20 +0300 Мы об этом "я считаю" можем спорить вечно. 237137 54 aen 2023-11-14 20:47:21 +0300 (Ответ для Anton Farygin на комментарий #53) > Мы об этом "я считаю" можем спорить вечно. Так надо тогда спорить, а не скандалить. Тем более публично. От закрытия баги проблема не исчезает, исчезает лишь репутация 237138 55 rider 2023-11-14 20:50:41 +0300 От переоткрытия исправлено тоже не будет. WONTFIX - это явно означает что это исправлено не будет. т.к. ошибкой не является - это специально сделанное поведение по умолчанию. 237139 56 aen 2023-11-14 21:02:49 +0300 (Ответ для Anton Farygin на комментарий #55) > От переоткрытия исправлено тоже не будет. > WONTFIX - это явно означает что это исправлено не будет. т.к. ошибкой не > является - это специально сделанное поведение по умолчанию. Решать надо сейчас, до бранчевания. Тем более, не надо прекращать обсуждение поднятой проблемы. Она есть и спасибо Антону, что он её поставил. И предложил решение, позволяющее релиз-менеджеру сохранить прежнее поведение. 237140 57 rider 2023-11-14 21:05:18 +0300 Да есть и другой вариант изменения этого поведения, без вмешательства в умолчания пакета. Эти конфиги можно перекрывать из других пакетов. Тот, кому нужно - сделает пакет с другим поведением и добавит его в дистрибутив. 237141 58 rider 2023-11-14 21:06:43 +0300 А обсуждение именно этой проблемы лучше всего вести по регламенту: https://www.altlinux.org/Policy_Policy Т.к это поведение есть во многих пакетах. 237142 59 aen 2023-11-14 21:11:44 +0300 (Ответ для Anton Farygin на комментарий #57) > Да есть и другой вариант изменения этого поведения, без вмешательства в > умолчания пакета. > > Эти конфиги можно перекрывать из других пакетов. > Тот, кому нужно - сделает пакет с другим поведением и добавит его в > дистрибутив. Безопасность, полагаю, должна быть по умолчанию. А откручивание гаек -- опция. 237160 60 sin 2023-11-15 04:14:10 +0300 Мне эта проблема близка. Кажется пересекающейся с двумя историями: темой групповых политик в домене и темой политик безопасности по дефолту. Кроме того, мы, как раз приступаем к планированию новых модулей управления. В данном, текущем случае, я поддерживаю больше ldv@ и antohami@. PackageKit не должен ставить пакеты без пароля. Это жесть. Это любой скрипт может от пользователя много чего натворить. Ну, по дефолту, это просто неприемлемо, конечно. Насколько я понимаю rider@ и zerg@, то у них по другому не работает схема с offline updates. Ну, извините. Я уверен, что необходимое поведение можно организовать и без такого откручивания гаек. Попробую разобраться - напишу о результатах. Предложение rider@ про политику безопасности поддерживаю. Давно планирую привлечь к этой задаче ресурсы. Тут нужно и время, и люди, и видение предварительное, и форма понятная как все это лучше представить. 237163 61 antohami 2023-11-15 04:20:18 +0300 (Ответ для Evgeny Sinelnikov на комментарий #60) > Насколько я понимаю rider@ и zerg@, то у них по другому не работает схема с > offline updates. Ну, извините. Я уверен, что необходимое поведение можно > организовать и без такого откручивания гаек. Попробую разобраться - напишу о > результатах. Оно работает: https://bugzilla.altlinux.org/show_bug.cgi?id=48431#c32 Пакеты устанавливает сервис после перезагрузки, а не пользователь. 237165 62 sin 2023-11-15 04:30:01 +0300 (Ответ для Антон Мидюков на комментарий #32) > (Ответ для Anton Farygin на комментарий #29) > > Стандартный сценарий - установка/доустановка пакетов и обновление системы. > > Мои эксперименты показали, что обновиться можно без этого правила, так как > обновляет сервис packagekit-offline-update.service после перезагрузки. > Подготовить обновление может пользователь без ввода пароля через discover > или gnome-software, нажав соответствующую кнопочку. Т.е. для обновления > системы это правило не нужно. Получается, что либо rider@ и zerg@ хотят, всё-таки, странного, либо есть объективная причина, которая не проговаривается. Нужно разобраться. 237166 63 aen 2023-11-15 04:40:11 +0300 (Ответ для Evgeny Sinelnikov на комментарий #60) > Предложение rider@ про политику безопасности поддерживаю. Давно планирую > привлечь к этой задаче ресурсы. Тут нужно и время, и люди, и видение > предварительное, и форма понятная как все это лучше представить. Нужно различать политики безопасности Sisyphus , обсуждаемую Тим, и политику безопасности продуктов "Базальт СПО". Это неизбежно связанные документы, но разрабатываются и принимаются по разному. 237167 64 sin 2023-11-15 04:50:20 +0300 (Ответ для AEN на комментарий #63) > Нужно различать политики безопасности Sisyphus , обсуждаемую Тим, > и политику безопасности продуктов "Базальт СПО". > Это неизбежно связанные документы, но разрабатываются и принимаются по > разному. Согласен. Хотя разницу не особо не ощущаю, если честно. Эти политики имеют кучу взаимозависимостей. Их нужно собрать в список, назвать, дать технические пояснения и сравнить. Думаю будет много совпадений. 237168 65 aen 2023-11-15 05:01:06 +0300 (Ответ для Evgeny Sinelnikov на комментарий #64) > (Ответ для AEN на комментарий #63) > > Нужно различать политики безопасности Sisyphus , обсуждаемую Тим, > > и политику безопасности продуктов "Базальт СПО". > > Это неизбежно связанные документы, но разрабатываются и принимаются по > > разному. > > Согласен. Хотя разницу не особо не ощущаю, если честно. Эти политики имеют > кучу взаимозависимостей. Их нужно собрать в список, назвать, дать > технические пояснения и сравнить. Думаю будет много совпадений. Политика безопасности Базальта -- внутренний документ фирмы, относящийся ко всему спектру её продуктов. Полиси тим -- публичный продукт сообщества. Конечно, они не должны противоречить друг другу. 237174 66 rider 2023-11-15 07:55:05 +0300 (Ответ для AEN на комментарий #59) > (Ответ для Anton Farygin на комментарий #57) > > Да есть и другой вариант изменения этого поведения, без вмешательства в > > умолчания пакета. > > > > Эти конфиги можно перекрывать из других пакетов. > > Тот, кому нужно - сделает пакет с другим поведением и добавит его в > > дистрибутив. > > Безопасность, полагаю, должна быть по умолчанию. А откручивание гаек -- > опция. Возможно, но для этого всё равно нужно нормальное Policy. Будет Policy - приведём в состояние с ним все затрагиваемые пакеты. 237175 67 rider 2023-11-15 07:56:59 +0300 (Ответ для Evgeny Sinelnikov на комментарий #62) > (Ответ для Антон Мидюков на комментарий #32) > > (Ответ для Anton Farygin на комментарий #29) > > > Стандартный сценарий - установка/доустановка пакетов и обновление системы. > > > > Мои эксперименты показали, что обновиться можно без этого правила, так как > > обновляет сервис packagekit-offline-update.service после перезагрузки. > > Подготовить обновление может пользователь без ввода пароля через discover > > или gnome-software, нажав соответствующую кнопочку. Т.е. для обновления > > системы это правило не нужно. > > Получается, что либо rider@ и zerg@ хотят, всё-таки, странного, либо есть > объективная причина, которая не проговаривается. Нужно разобраться. Моё желание простое и должно быть понятно всем участникам - я против изменения устоявшегося поведения по умолчанию без обоснований. Обоснование в данном случае может быть одно - это утверждённая по правилам Team политика безопасности в отношении приложений, использующих механизм polkit. 237176 68 aen 2023-11-15 08:28:57 +0300 (Ответ для Anton Farygin на комментарий #67) > (Ответ для Evgeny Sinelnikov на комментарий #62) > > (Ответ для Антон Мидюков на комментарий #32) > > > (Ответ для Anton Farygin на комментарий #29) > > > > Стандартный сценарий - установка/доустановка пакетов и обновление системы. > > > > > > Мои эксперименты показали, что обновиться можно без этого правила, так как > > > обновляет сервис packagekit-offline-update.service после перезагрузки. > > > Подготовить обновление может пользователь без ввода пароля через discover > > > или gnome-software, нажав соответствующую кнопочку. Т.е. для обновления > > > системы это правило не нужно. > > > > Получается, что либо rider@ и zerg@ хотят, всё-таки, странного, либо есть > > объективная причина, которая не проговаривается. Нужно разобраться. > > Моё желание простое и должно быть понятно всем участникам - я против > изменения устоявшегося поведения по умолчанию без обоснований. Чье же конкретно поведение в данном случае ты не хочешь менять? > 238912 69 antohami 2023-12-13 10:45:14 +0300 (Ответ для Anton Farygin на комментарий #67) > (Ответ для Evgeny Sinelnikov на комментарий #62) > > (Ответ для Антон Мидюков на комментарий #32) > > > (Ответ для Anton Farygin на комментарий #29) > > > > Стандартный сценарий - установка/доустановка пакетов и обновление системы. > > > > > > Мои эксперименты показали, что обновиться можно без этого правила, так как > > > обновляет сервис packagekit-offline-update.service после перезагрузки. > > > Подготовить обновление может пользователь без ввода пароля через discover > > > или gnome-software, нажав соответствующую кнопочку. Т.е. для обновления > > > системы это правило не нужно. > > > > Получается, что либо rider@ и zerg@ хотят, всё-таки, странного, либо есть > > объективная причина, которая не проговаривается. Нужно разобраться. > > Моё желание простое и должно быть понятно всем участникам - я против > изменения устоявшегося поведения по умолчанию без обоснований. Вот после того, как вчера пропустили в p10: https://packages.altlinux.org/ru/tasks/335797/ это больше не аргумент, потому что поменялось глобальное поведение, которое было у нас больше 10 лет. (Ответ для Anton Farygin на комментарий #44) > Я вам даже более того скажу - сейчас это поведение можно считать > "стандартом" хотя бы из-за того, что другого поведения нет: > > # grep wheel /usr/share/polkit-1/rules.d/* > /usr/share/polkit-1/rules.d/org.freedesktop.bolt.rules: > subject.isInGroup("wheel")) { > /usr/share/polkit-1/rules.d/org.freedesktop.Flatpak.rules: > subject.isInGroup("wheel")) { > /usr/share/polkit-1/rules.d/org.freedesktop.fwupd.rules: > subject.isInGroup("wheel")) { > Вот я ничего страшного не вижу, что администраторам всё это разрешают. А вот в том, что без пароля можно установить произвольный пакет из репозитория и сломать систему (это же может сделать скрипт!) вижу. Например: pkcon install apt-conf-ignore-systemd И всё, система на systemd не будет обновляться корректно. Или установить polkit-rule-packagekit-allow-remove, а потом всё поудалять. Вот если бы разрешалась установка только приложений appstream, то никаких вопросов бы к умолчанию такому не было. Нельзя же быть уверенным, что какой-то пакет в репозитории не сломает всю систему. Поэтому при установке пакетов нужно запрашивать обязательно пароль. 238916 70 sin 2023-12-13 11:11:20 +0300 Какая жесть, то есть вот такого правила больше нет: $ sudo cat /etc/polkit-1/rules.d/50-default.rules /* -*- mode: js; js-indent-level: 4; indent-tabs-mode: nil -*- */ // DO NOT EDIT THIS FILE, it will be overwritten on update // // Default rules for polkit // // See the polkit(8) man page for more information // about configuring polkit. polkit.addAdminRule(function(action, subject) { return ["unix-group:wheel"]; }); А в чём причина такого резкой смены поведения? Как быть теперь с доменными пользователями, которые доступ могли получить исключительно по группе. Или предлагается каждому из тысяч пользователей вручную на тысячах машин в админские привилегии назначать? Или всем дружно вспоминать и учить на тысячах машин пароль локального рута? А кто такое пропустил в стабильный бранч? А что он предлагает делать с клиентами, у которых доступ отвалится? 268661 71 antohami 2025-07-09 16:58:55 +0300 Предлагаю вернуться к вопросу. Из репозитория можно установить правило polkit [1], которое позволяет удалять любые пакеты пользователю группы wheel. Можно установить sudo, которое старательно выпилили из kworkstation. 1. polkit-rule-packagekit-allow-remove 268665 72 zerg 2025-07-09 17:11:08 +0300 (Ответ для Антон Мидюков на комментарий #71) > Можно установить sudo, которое старательно выпилили из kworkstation. Его уже запилил обратно etcnet #54096 268675 73 zerg 2025-07-09 18:32:45 +0300 (Ответ для Антон Мидюков на комментарий #71) > Предлагаю вернуться к вопросу. К какому именно? 268676 74 antohami 2025-07-09 18:43:48 +0300 (Ответ для Sergey V Turchin на комментарий #73) > (Ответ для Антон Мидюков на комментарий #71) > > Предлагаю вернуться к вопросу. > К какому именно? (Ответ для Антон Мидюков на комментарий #0) > packagekit позволяет установить любой пакет пользователю из группы wheel без > пароля: > pkcon install любой_пакет > > Предлагаю вынести в отдельный пакет polkit правило > /usr/share/polkit-1/rules.d/org.freedesktop.packagekit.rules, которое за это > отвечает. > Пусть добавление этого правила в дистрибутив будет на совести > релиз-менеджера этого дистрибутива или администратора, установившего этот > пакет. 268679 75 zerg 2025-07-09 19:08:13 +0300 Перед тем, как спросить я перечитал на всякий comment#0, но там нет вопросов. Предложение вернуться к обсуждению возможности запрета по умолчанию установки без пароля? Я не против, но нужен ли вообще packagekit на этих системах? 268681 76 antohami 2025-07-09 19:40:40 +0300 (Ответ для Sergey V Turchin на комментарий #75) > Перед тем, как спросить я перечитал на всякий comment#0, но там нет вопросов. > Предложение вернуться к обсуждению возможности запрета по умолчанию > установки без пароля? Да. > > Я не против, но нужен ли вообще packagekit на этих системах? На Рабочей станции? Да, нужен, для оффлайн-обновления, для установки приложений через gnome-software. 268710 77 zerg 2025-07-10 10:36:11 +0300 Ок. А зачем не давать локально залогиненому wheel-у устанавливать пакеты? Не нашёл полезных поводов ни для дома ни для организации. 268712 78 antohami 2025-07-10 10:49:06 +0300 (Ответ для Sergey V Turchin на комментарий #77) > Ок. А зачем не давать локально залогиненому wheel-у устанавливать пакеты? > Не нашёл полезных поводов ни для дома ни для организации. 1. Потому что это должен делать root и пользователи, авторизующиеся как root. 2. Пользователь wheel, не зная пароля root, может установить пакет с правилом polkit, которое позволят ему ещё и удалять пакеты. И мало ли какое ещё правило polkit может быть собрано в репозитории. То есть разрешая ему ставить пакеты, мы открываем ему возможность расширять свои привилегии. 3. Пользователь wheel может установить пакеты, которые систему сломают. 4. Пользователь wheel может запустить недоверенный скрипт, который воспользуется возможностью установки пакетов без ввода пароля и откроет злоумышленнику доступ к системе. 5. Пользователь wheel может отойти от компьютера, забыв заблокировать сеанс. В результате облегчаем злоумышленнику задачу по получению доступа к системе. То есть убираем потенциальную дыру в безопасности. И наконец. Неужели сложно ввести пароль root при установке приложения? 268714 79 zerg 2025-07-10 11:30:07 +0300 > > Не нашёл полезных поводов ни для дома ни для организации. > > 1. Потому что это должен Я торжественно освобождаю всех от долгов. ;-) По вышеперечисленному проблемы только на домашней системе, верно? 268715 80 antohami 2025-07-10 11:32:26 +0300 (Ответ для Sergey V Turchin на комментарий #79) > > > Не нашёл полезных поводов ни для дома ни для организации. > > > > 1. Потому что это должен > Я торжественно освобождаю всех от долгов. ;-) > > По вышеперечисленному проблемы только на домашней системе, верно? Почему это? 268716 81 zerg 2025-07-10 11:36:02 +0300 (Ответ для Антон Мидюков на комментарий #78) > это должен делать root и пользователи, авторизующиеся как root. Это плохо. Вместо этого администратор работает не от root, а от простого пользователя, состоящего в группе wheel. Достаточно не давать возможность при установке добавить 1-го пользователя в группу wheel. 268718 82 zerg 2025-07-10 11:36:45 +0300 (Ответ для Антон Мидюков на комментарий #80) > > По вышеперечисленному проблемы только на домашней системе, верно? > Почему это? А откуда в организации взялись простые пользователи с такими возможностями? 268720 83 antohami 2025-07-10 11:44:11 +0300 (Ответ для Sergey V Turchin на комментарий #81) > (Ответ для Антон Мидюков на комментарий #78) > > это должен делать root и пользователи, авторизующиеся как root. > Это плохо. Вместо этого администратор работает не от root, а от простого > пользователя, состоящего в группе wheel. Под "авторизующиеся как root" я имел в виду пользователей группы wheel, повышающие свои привилегии через polkit для конкретного действия - установки через packagekit. Администратор и работает как простой пользователь, но при необходимости выполнить установку пакетов вводит пароль root. Поэтому это хорошо, а не плохо. В организациях вместо пароля root, могут настраивать ввод пароля пользователя группы wheel. Но это должны именно настроить. И почувствуйте разницу между установкой с вводом своего пароля и установкой без ввода пароля. > > Достаточно не давать возможность при установке добавить 1-го пользователя в > группу wheel. Нет. Это вообще не имеет отношения к делу. 268721 84 antohami 2025-07-10 11:45:11 +0300 (Ответ для Sergey V Turchin на комментарий #82) > (Ответ для Антон Мидюков на комментарий #80) > > > По вышеперечисленному проблемы только на домашней системе, верно? > > Почему это? > А откуда в организации взялись простые пользователи с такими возможностями? Очевидно, что это администраторы, а не простые пользователи. 268725 85 zerg 2025-07-10 11:50:52 +0300 (Ответ для Антон Мидюков на комментарий #84) > > А откуда в организации взялись простые пользователи с такими возможностями? > Очевидно, что это администраторы, а не простые пользователи. Тогда всё в порядке. Они знают, что делают. 268727 86 zerg 2025-07-10 11:52:08 +0300 (Ответ для Антон Мидюков на комментарий #78) > 5. Пользователь wheel может отойти от компьютера, забыв заблокировать сеанс. Лошара, а не админ. :-) 268730 87 antohami 2025-07-10 12:00:27 +0300 (Ответ для Sergey V Turchin на комментарий #86) > (Ответ для Антон Мидюков на комментарий #78) > > 5. Пользователь wheel может отойти от компьютера, забыв заблокировать сеанс. > Лошара, а не админ. :-) Это называется человеческий фактор. 268746 88 zerg 2025-07-10 12:20:41 +0300 (Ответ для Антон Мидюков на комментарий #87) > > > 5. Пользователь wheel может отойти от компьютера, забыв заблокировать сеанс. > > Лошара, а не админ. :-) > Это называется человеческий фактор. Если официально в приказе на увольнение, то можно и так. ;-) 268838 89 zerg 2025-07-11 09:57:54 +0300 https://t.me/alt_linux/538149 Вот, например, решается удалением packagekit. Но, если какой-нибудь alterator-components начнёт его использовать, то удаление станет невозможно. 268839 90 antohami 2025-07-11 10:02:05 +0300 (Ответ для Sergey V Turchin на комментарий #89) > https://t.me/alt_linux/538149 > Вот, например, решается удалением packagekit. Можно не заметить, как packagekit залетит при обновлении. Из коробки гайки должны быть завинчены. Бага именно об этом. 268841 91 zerg 2025-07-11 10:04:28 +0300 (Ответ для Sergey V Turchin на комментарий #9) > В принципе, я не против отдельного пакета. 268842 92 zerg 2025-07-11 10:05:21 +0300 Мне достаточно будет, если я не пропущу его прохождение в p11. 268845 93 antohami 2025-07-11 10:13:32 +0300 (Ответ для Sergey V Turchin на комментарий #91) > (Ответ для Sergey V Turchin на комментарий #9) > > В принципе, я не против отдельного пакета. Так надо сделать. $ ssh gyle acl sisyphus packagekit show packagekit rider darktemplar zerg imz (Ответ для Sergey V Turchin на комментарий #92) > Мне достаточно будет, если я не пропущу его прохождение в p11. Поставь зависимость у пакета alt-kworkstation-addon на новый пакет вместо этого. 268848 94 zerg 2025-07-11 10:18:10 +0300 (Ответ для Антон Мидюков на комментарий #93) > Поставь зависимость у пакета alt-kworkstation-addon на новый пакет вместо > этого. Само собой. Я лишь хочу, чтобы они в один день провалились в p11. 269540 95 antohami 2025-07-21 15:57:42 +0300 Бага будет исправляться? 269557 96 zerg 2025-07-21 18:54:57 +0300 packagekit 1.3.0-alt5 269562 97 antohami 2025-07-21 22:23:19 +0300 (Ответ для Sergey V Turchin на комментарий #96) > packagekit 1.3.0-alt5 Спасибо!