пользователь в группе wheel имеет и так слишком много привилегий, не надо усложнять жизнь.

(Ответ для Anton Farygin на комментарий #1)
> пользователь в группе wheel имеет и так слишком много привилегий, не надо
> усложнять жизнь.

antohami@ предлагает не исключать этот вариант, а оставить его на усмотрение релиз-менеджера.
И предлагает простое решение. WONTFIX не про это.

Так и задумано. Устанавливать может, а удалять -- фигу.

(Ответ для Sergey V Turchin на комментарий #3)
> Так и задумано. Устанавливать может, а удалять -- фигу.

Ладно. Я у себя это недоразумение исправлю. Выкрутить правило обратно не проблема:
https://bugzilla.altlinux.org/show_bug.cgi?id=41895#c3

Просьба ещё раз прочитать и прислушаться к тому, что написал Антон.

(Ответ для Антон Мидюков на комментарий #4)
> Ладно. Я у себя это недоразумение исправлю. Выкрутить правило обратно не
> проблема:
> https://bugzilla.altlinux.org/show_bug.cgi?id=41895#c3
Это совсем не понял.
У меня и такой packagekit и polkit-rule-admin-root. Выкручивание чего именно и что именно может исправить?

(Ответ для Dmitry V. Levin на комментарий #5)
> Просьба ещё раз прочитать и прислушаться к тому, что написал Антон.
Где взять синтезатор голоса Антона. ;-)

(Ответ для 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

Будет пароль админа спрашивать.

Но бага изначально о том, что умолчание не должно быть разрешающим. Кто хочет разрешить, устанавливает пакет с разрешающим правилом. А вы вынуждаете делать наоборот. Писать запрещающие правила, так как дефолт разрешающий.

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

(Ответ для AEN на комментарий #2)
> (Ответ для Anton Farygin на комментарий #1)
> > пользователь в группе wheel имеет и так слишком много привилегий, не надо
> > усложнять жизнь.
> 
> antohami@ предлагает не исключать этот вариант, а оставить его на усмотрение
> релиз-менеджера.
> И предлагает простое решение. WONTFIX не про это.

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

(Ответ для Антон Мидюков на комментарий #8)
> Но бага изначально о том, что умолчание не должно быть разрешающим. Кто
> хочет разрешить, устанавливает пакет с разрешающим правилом. А вы вынуждаете
> делать наоборот. Писать запрещающие правила, так как дефолт разрешающий.
С этим можно поспорить. У нас много чего разрешено по умолчанию так или иначе.

P.S.
Или, наоборот, пример "правильного поведения". Попробуйте на регулярке простого пользователя заставить включить возможность расшаривать пользовательские каталоги по samba, причём сделать это правильно. Он скорее повесится.

(Ответ для Sergey V Turchin на комментарий #11)
> (Ответ для Антон Мидюков на комментарий #8)
> > Но бага изначально о том, что умолчание не должно быть разрешающим. Кто
> > хочет разрешить, устанавливает пакет с разрешающим правилом. А вы вынуждаете
> > делать наоборот. Писать запрещающие правила, так как дефолт разрешающий.
> С этим можно поспорить. У нас много чего разрешено по умолчанию так или
> иначе.
> 
> P.S.
> Или, наоборот, пример "правильного поведения". Попробуйте на регулярке
> простого пользователя заставить включить возможность расшаривать
> пользовательские каталоги по samba, причём сделать это правильно. Он скорее
> повесится.

Регулярки не для простого пользователя. Некорректный пример.

Поясню для истории:
пользователь в группе wheel имеет повышенные привилегии в системы - в большинстве конфигураций он может делать многие гораздо более серьёзные вещи, чем ставить пакеты через packagekit.

Если релиз-менеджер не доверяет пользователю, то не надо его включать в группу wheel.

(Ответ для AEN на комментарий #12)
> Регулярки не для простого пользователя. Некорректный пример.
А вы сами попробуйте. ;-)

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

Но wheel тут точно не виноват, не надо его трогать (и ломать существующее поведение).

(Ответ для Sergey V Turchin на комментарий #14)
> (Ответ для AEN на комментарий #12)
> > Регулярки не для простого пользователя. Некорректный пример.
> А вы сами попробуйте. ;-)

Спасибо, но я это делал.

Алексей, ты точно не пробовал расшаривать папку через samba на регулярке.
Не флудите, пожалуйста.

(Ответ для AEN на комментарий #16)
> Спасибо, но я это делал.
Нет. ;-) https://www.altlinux.org/Samba/Usershares

(Ответ для Anton Farygin на комментарий #15)
> Возможно, было бы неплохо ввести дополнительную группу с правами обновления
> системы и установки пакетов.
IMHO уже лучше правила polkit изменить, только так, чтоб никому не испортить.

(Ответ для Anton Farygin на комментарий #17)
> Алексей, ты точно не пробовал расшаривать папку через samba на регулярке.
> Не флудите, пожалуйста.

Никакого флуда. Года два назад делал, установив пакеты.

(Ответ для AEN на комментарий #12)
> Регулярки не для простого пользователя. Некорректный пример.
Ок, вот корректный:
простой пользователь устанавливает К-10.0, обновляется, после чего пытается восстановить сломанное расшаривание по инструкции https://www.altlinux.org/Samba/Usershares

(In reply to Anton Farygin from comment #10)
> Нет, сейчас умолчания правильные, не надо их оставлять на усмотрение
> релиз-менеджера.

На самом деле нет.

(In reply to Sergey V Turchin from comment #11)
> (Ответ для Антон Мидюков на комментарий #8)
> > Но бага изначально о том, что умолчание не должно быть разрешающим. Кто
> > хочет разрешить, устанавливает пакет с разрешающим правилом. А вы вынуждаете
> > делать наоборот. Писать запрещающие правила, так как дефолт разрешающий.
> С этим можно поспорить. У нас много чего разрешено по умолчанию так или
> иначе.

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

(Ответ для Dmitry V. Levin на комментарий #22)
> якобы
Только эти "якобы" и "пока" там не мои.
Ну и мою позицию я определил в comment#9.

Ну так это же просто - эти "баги" на самом деле очень хорошие фичи. И обсуждаемая здесь относится к их числу.

Ну или ошибка (FR) должна звучать каким-то другим образом.

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

Прошу ответить на вопрос:
Зачем понадобилось разрешать установку пакетов без ввода пароля?

Для того, что бы пользователь из группы wheel мог делать это без ввода пароля.

(Ответ для Anton Farygin на комментарий #27)
> Для того, что бы пользователь из группы wheel мог делать это без ввода
> пароля.

Под "это" скрывается только "установка произвольных пакетов" или что-то ещё?

Стандартный сценарий - установка/доустановка пакетов и обновление системы.

(Ответ для Anton Farygin на комментарий #29)
> Стандартный сценарий - установка/доустановка пакетов и обновление системы.

Что это за "стандарт"? Безопасностью нашей системы занимался ldv@. Есть требования ФСТЭК.
Давайте все же разберемся. Хотелось бы  услышать Диму и Дениса (подключаю его).

Группа wheel была задумана не как замена root, а как группа, членам которой может быть позволено авторизоваться для выполнения тех или иных привилегированных операций.

Тот факт, что кому-то показалось удобным не спрашивать у членов группы wheel authentication tokens и сразу давать привилегированный доступ, не значит, что это хорошее поведение по-умолчанию, и тем более не значит, что позволено пытаться запрещать поведение, которое другие считают более правильным и подходящим для решаемых задач.

Это валидный багрепорт, поэтому, пожалуйста, не надо его закрывать как NOTABUG.

(Ответ для Anton Farygin на комментарий #29)
> Стандартный сценарий - установка/доустановка пакетов и обновление системы.

Мои эксперименты показали, что обновиться можно без этого правила, так как обновляет сервис packagekit-offline-update.service после перезагрузки. Подготовить обновление может пользователь без ввода пароля через discover или gnome-software, нажав соответствующую кнопочку. Т.е. для обновления системы это правило не нужно.

(Ответ для AEN на комментарий #30)
> (Ответ для Anton Farygin на комментарий #29)
> > Стандартный сценарий - установка/доустановка пакетов и обновление системы.
> 
> Что это за "стандарт"? Безопасностью нашей системы занимался ldv@. Есть
> требования ФСТЭК.
> Давайте все же разберемся. Хотелось бы  услышать Диму и Дениса (подключаю
> его).

ФСТЭК то тут при чём ? Там обновления идут вообще по другому пути и packagekit не используется.

Этот багрепорт не валиден, т.к. нет никакой ошибки, не нарушены никакие правила и требования - нигде нет формальных требований работать именно так а не иначе.

Можете рассказать истинную причину появления этой ошибки ?

(Ответ для Anton Farygin на комментарий #33)
> (Ответ для AEN на комментарий #30)
> > (Ответ для Anton Farygin на комментарий #29)
> > > Стандартный сценарий - установка/доустановка пакетов и обновление системы.
> > 
> > Что это за "стандарт"? Безопасностью нашей системы занимался ldv@. Есть
> > требования ФСТЭК.
> > Давайте все же разберемся. Хотелось бы  услышать Диму и Дениса (подключаю
> > его).
> 
> ФСТЭК то тут при чём ? Там обновления идут вообще по другому пути и
> packagekit не используется.
> 
> Этот багрепорт не валиден, т.к. нет никакой ошибки, не нарушены никакие
> правила и требования - нигде нет формальных требований работать именно так а
> не иначе.
> 
> Можете рассказать истинную причину появления этой ошибки ?

Я знакомился сегодня с packagekit. Был удивлён, отрапортовал.
Не надо искать то, чего нет.

А это поведение почему-то никого не беспокоит ?
https://forum.altlinux.org/index.php?topic=41933.0

В общем если будет написана и согласована со всеми участниками единая политика безопасности, то и этот пакет будет ей следовать.

.

(Ответ для Anton Farygin на комментарий #33)
> (Ответ для AEN на комментарий #30)
> > (Ответ для Anton Farygin на комментарий #29)
> > > Стандартный сценарий - установка/доустановка пакетов и обновление системы.
> > 
> > Что это за "стандарт"? Безопасностью нашей системы занимался ldv@. Есть
> > требования ФСТЭК.
> > Давайте все же разберемся. Хотелось бы  услышать Диму и Дениса (подключаю
> > его).
> 
> ФСТЭК то тут при чём ? Там обновления идут вообще по другому пути и
> packagekit не используется.
> 
> Этот багрепорт не валиден, т.к. нет никакой ошибки, не нарушены никакие
> правила и требования - нигде нет формальных требований работать именно так а
> не иначе.

Ты же сам писал про "стандартный сценарий". Где же стандарты? 
> 
> Можете рассказать истинную причину появления этой ошибки ?
Всё описано Антоном. Забота о безопасности "из коробки".
От тебя тоже нужны аргументы, не закрывать багу Дима уже просил. 
Давай говорить серьёзно и конструктивно, без конфликтов на ровном месте. Пожалуйста.

Пожалуйста, прекратите закрывать валидный багрепорт!

(Ответ для Anton Farygin на комментарий #35)
> А это поведение почему-то никого не беспокоит ?
> https://forum.altlinux.org/index.php?topic=41933.0
> 
> В общем если будет написана и согласована со всеми участниками единая
> политика безопасности, то и этот пакет будет ей следовать.

Не надо ставить условия, пожалуйста.

Дима, был бы валидный - я бы его не закрывал. 
Можем продолжать до бесконечности, но в любом случае прежде чем считать этот багрепорт валидным - надо описать условия использования, которые этот багрепорт нарушает.

(Ответ для AEN на комментарий #39)
> (Ответ для Anton Farygin на комментарий #35)
> > А это поведение почему-то никого не беспокоит ?
> > https://forum.altlinux.org/index.php?topic=41933.0
> > 
> > В общем если будет написана и согласована со всеми участниками единая
> > политика безопасности, то и этот пакет будет ей следовать.
> 
> Не надо ставить условия, пожалуйста.

Это условия сосуществования разных взглядов на жизнь в одной экосистеме.

(Ответ для Anton Farygin на комментарий #41)
> (Ответ для AEN на комментарий #39)
> > (Ответ для Anton Farygin на комментарий #35)
> > > А это поведение почему-то никого не беспокоит ?
> > > https://forum.altlinux.org/index.php?topic=41933.0
> > > 
> > > В общем если будет написана и согласована со всеми участниками единая
> > > политика безопасности, то и этот пакет будет ей следовать.
> > 
> > Не надо ставить условия, пожалуйста.
> 
> Это условия сосуществования разных взглядов на жизнь в одной экосистеме.

Условия сосуществования -- конструктивное обсуждение, а не закрытие обсуждаемой темы. 
Если взгляды разные, то тем более нельзя ставить условия.

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

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

# 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 без повода - давайте сделаем правила, договоримся о них и будем следовать.

(Ответ для Anton Farygin на комментарий #43)
> Пожалуйста, не надо переоткрывать - я не считаю это поведение ошибкой и буду
> считать только при появлении единого для всех систем документа,
> определяющего политику безопасности и в случае, если этот пакет будет
> нарушать ту самую политику безопасности.

Ты можешь считать как хочешь, но  открывший багу считает иначе. Не надо тут командовать. Тем более что бага уже на nobody, а не на тебе.

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

Напиши. 
Зачем тебе конфликт?

Вот и я не понимаю что ты тут устраиваешь на ровном месте.

у нас есть стандартный механизм утверждения политик упаковки пакетов в репозитории:
https://www.altlinux.org/Policy_Policy

Если кого-то не устраивает поведение по умолчанию пакетов, использующих мезанизм polkit для доступа к привелегиям в связке с wheel - он может написать Policy и предложить его на утверждение в devel.

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

(Ответ для Anton Farygin на комментарий #48)
> Вот и я не понимаю что ты тут устраиваешь на ровном месте.
> 
> у нас есть стандартный механизм утверждения политик упаковки пакетов в
> репозитории:
> https://www.altlinux.org/Policy_Policy
> 
> Если кого-то не устраивает поведение по умолчанию пакетов, использующих
> мезанизм polkit для доступа к привелегиям в связке с wheel - он может
> написать Policy и предложить его на утверждение в devel.
> 
> Я с удовольствием присоединюсь к этому обсуждению и уверен, что там и таким
> способом мы сможем выработать единый подход к решению обсуждаемой задачи.

Предложение Антона нарушает Policy?

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

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

Наличие принятого Policy будет веским основанием.

.

Я считаю, что багрепорт является валидным, и этого достаточно, чтобы он оставался открытым.

Мы об этом "я считаю" можем спорить вечно.

(Ответ для Anton Farygin на комментарий #53)
> Мы об этом "я считаю" можем спорить вечно.

Так надо тогда спорить, а не скандалить. 
Тем более публично. 
От закрытия баги проблема не исчезает, исчезает лишь репутация

От переоткрытия исправлено тоже не будет.
WONTFIX - это явно означает что это исправлено не будет. т.к. ошибкой не является - это специально сделанное поведение по умолчанию.

(Ответ для Anton Farygin на комментарий #55)
> От переоткрытия исправлено тоже не будет.
> WONTFIX - это явно означает что это исправлено не будет. т.к. ошибкой не
> является - это специально сделанное поведение по умолчанию.

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

Да есть и другой вариант изменения этого поведения, без вмешательства в умолчания пакета.

Эти конфиги можно перекрывать из других пакетов. 
Тот, кому нужно - сделает пакет с другим поведением и добавит его в дистрибутив.

А обсуждение именно этой проблемы лучше всего вести по регламенту:
https://www.altlinux.org/Policy_Policy

Т.к это поведение есть во многих пакетах.

(Ответ для Anton Farygin на комментарий #57)
> Да есть и другой вариант изменения этого поведения, без вмешательства в
> умолчания пакета.
> 
> Эти конфиги можно перекрывать из других пакетов. 
> Тот, кому нужно - сделает пакет с другим поведением и добавит его в
> дистрибутив.

Безопасность, полагаю, должна быть по умолчанию. А откручивание гаек -- опция.

Мне эта проблема близка. Кажется пересекающейся с двумя историями: темой групповых политик в домене и темой политик безопасности по дефолту. Кроме того, мы, как раз приступаем к планированию новых модулей управления.

В данном, текущем случае, я поддерживаю больше ldv@ и antohami@. PackageKit не должен ставить пакеты без пароля. Это жесть. Это любой скрипт может от пользователя много чего натворить. Ну, по дефолту, это просто неприемлемо, конечно.

Насколько я понимаю rider@ и zerg@, то у них по другому не работает схема с offline updates. Ну, извините. Я уверен, что необходимое поведение можно организовать и без такого откручивания гаек. Попробую разобраться - напишу о результатах.

Предложение rider@ про политику безопасности поддерживаю. Давно планирую привлечь к этой задаче ресурсы. Тут нужно и время, и люди, и видение предварительное, и форма понятная как все это лучше представить.

(Ответ для Evgeny Sinelnikov на комментарий #60)
> Насколько я понимаю rider@ и zerg@, то у них по другому не работает схема с
> offline updates. Ну, извините. Я уверен, что необходимое поведение можно
> организовать и без такого откручивания гаек. Попробую разобраться - напишу о
> результатах.

Оно работает: https://bugzilla.altlinux.org/show_bug.cgi?id=48431#c32
Пакеты устанавливает сервис после перезагрузки, а не пользователь.

(Ответ для Антон Мидюков на комментарий #32)
> (Ответ для Anton Farygin на комментарий #29)
> > Стандартный сценарий - установка/доустановка пакетов и обновление системы.
> 
> Мои эксперименты показали, что обновиться можно без этого правила, так как
> обновляет сервис packagekit-offline-update.service после перезагрузки.
> Подготовить обновление может пользователь без ввода пароля через discover
> или gnome-software, нажав соответствующую кнопочку. Т.е. для обновления
> системы это правило не нужно.

Получается, что либо rider@ и zerg@ хотят, всё-таки, странного, либо есть объективная причина, которая не проговаривается. Нужно разобраться.

(Ответ для Evgeny Sinelnikov на комментарий #60)

> Предложение rider@ про политику безопасности поддерживаю. Давно планирую
> привлечь к этой задаче ресурсы. Тут нужно и время, и люди, и видение
> предварительное, и форма понятная как все это лучше представить.

Нужно  различать политики безопасности Sisyphus , обсуждаемую Тим,
и политику безопасности продуктов "Базальт СПО".
Это неизбежно связанные документы, но разрабатываются и принимаются по разному.

(Ответ для AEN на комментарий #63)
> Нужно  различать политики безопасности Sisyphus , обсуждаемую Тим,
> и политику безопасности продуктов "Базальт СПО".
> Это неизбежно связанные документы, но разрабатываются и принимаются по
> разному.

Согласен. Хотя разницу не особо не ощущаю, если честно. Эти политики имеют кучу взаимозависимостей. Их нужно собрать в список, назвать, дать технические  пояснения и сравнить. Думаю будет много совпадений.

(Ответ для Evgeny Sinelnikov на комментарий #64)
> (Ответ для AEN на комментарий #63)
> > Нужно  различать политики безопасности Sisyphus , обсуждаемую Тим,
> > и политику безопасности продуктов "Базальт СПО".
> > Это неизбежно связанные документы, но разрабатываются и принимаются по
> > разному.
> 
> Согласен. Хотя разницу не особо не ощущаю, если честно. Эти политики имеют
> кучу взаимозависимостей. Их нужно собрать в список, назвать, дать
> технические  пояснения и сравнить. Думаю будет много совпадений.

Политика безопасности Базальта -- внутренний документ фирмы, относящийся ко всему спектру её продуктов. Полиси тим -- публичный продукт сообщества. 
Конечно, они не должны противоречить друг другу.

(Ответ для AEN на комментарий #59)
> (Ответ для Anton Farygin на комментарий #57)
> > Да есть и другой вариант изменения этого поведения, без вмешательства в
> > умолчания пакета.
> > 
> > Эти конфиги можно перекрывать из других пакетов. 
> > Тот, кому нужно - сделает пакет с другим поведением и добавит его в
> > дистрибутив.
> 
> Безопасность, полагаю, должна быть по умолчанию. А откручивание гаек --
> опция.

Возможно, но для этого всё равно нужно нормальное Policy.

Будет Policy - приведём в состояние с ним все затрагиваемые пакеты.

(Ответ для Evgeny Sinelnikov на комментарий #62)
> (Ответ для Антон Мидюков на комментарий #32)
> > (Ответ для Anton Farygin на комментарий #29)
> > > Стандартный сценарий - установка/доустановка пакетов и обновление системы.
> > 
> > Мои эксперименты показали, что обновиться можно без этого правила, так как
> > обновляет сервис packagekit-offline-update.service после перезагрузки.
> > Подготовить обновление может пользователь без ввода пароля через discover
> > или gnome-software, нажав соответствующую кнопочку. Т.е. для обновления
> > системы это правило не нужно.
> 
> Получается, что либо rider@ и zerg@ хотят, всё-таки, странного, либо есть
> объективная причина, которая не проговаривается. Нужно разобраться.

Моё желание простое и должно быть понятно всем участникам - я против изменения устоявшегося поведения по умолчанию без обоснований.

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

(Ответ для Anton Farygin на комментарий #67)
> (Ответ для Evgeny Sinelnikov на комментарий #62)
> > (Ответ для Антон Мидюков на комментарий #32)
> > > (Ответ для Anton Farygin на комментарий #29)
> > > > Стандартный сценарий - установка/доустановка пакетов и обновление системы.
> > > 
> > > Мои эксперименты показали, что обновиться можно без этого правила, так как
> > > обновляет сервис packagekit-offline-update.service после перезагрузки.
> > > Подготовить обновление может пользователь без ввода пароля через discover
> > > или gnome-software, нажав соответствующую кнопочку. Т.е. для обновления
> > > системы это правило не нужно.
> > 
> > Получается, что либо rider@ и zerg@ хотят, всё-таки, странного, либо есть
> > объективная причина, которая не проговаривается. Нужно разобраться.
> 
> Моё желание простое и должно быть понятно всем участникам - я против
> изменения устоявшегося поведения по умолчанию без обоснований.

Чье же конкретно поведение в данном случае ты не хочешь  менять? 
>

(Ответ для 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, то никаких вопросов бы к умолчанию такому не было. Нельзя же быть уверенным, что какой-то пакет в репозитории не сломает всю систему. Поэтому при установке пакетов нужно запрашивать обязательно пароль.

Какая жесть, то есть вот такого правила больше нет:

$ 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"];
});

А в чём причина такого резкой смены поведения?

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

Или предлагается каждому из тысяч пользователей вручную на тысячах машин в админские привилегии назначать? Или всем дружно вспоминать и учить на тысячах машин пароль локального рута?

А кто такое пропустил в стабильный бранч?

А что он предлагает делать с клиентами, у которых доступ отвалится?

Предлагаю вернуться к вопросу.
Из репозитория можно установить правило polkit [1], которое позволяет удалять любые пакеты пользователю группы wheel. Можно установить sudo, которое старательно выпилили из kworkstation. 

1. polkit-rule-packagekit-allow-remove

(Ответ для Антон Мидюков на комментарий #71)
> Можно установить sudo, которое старательно выпилили из kworkstation. 
Его уже запилил обратно etcnet #54096

(Ответ для Антон Мидюков на комментарий #71)
> Предлагаю вернуться к вопросу.
К какому именно?

(Ответ для Sergey V Turchin на комментарий #73)
> (Ответ для Антон Мидюков на комментарий #71)
> > Предлагаю вернуться к вопросу.
> К какому именно?

(Ответ для Антон Мидюков на комментарий #0)
> packagekit позволяет установить любой пакет пользователю из группы wheel без
> пароля:
> pkcon install любой_пакет
> 
> Предлагаю вынести в отдельный пакет polkit правило
> /usr/share/polkit-1/rules.d/org.freedesktop.packagekit.rules, которое за это
> отвечает.
> Пусть добавление этого правила в дистрибутив будет на совести
> релиз-менеджера этого дистрибутива или администратора, установившего этот
> пакет.

Перед тем, как спросить я перечитал на всякий comment#0, но там нет вопросов.
Предложение вернуться к обсуждению возможности запрета по умолчанию установки без пароля?

Я не против, но нужен ли вообще packagekit на этих системах?

(Ответ для Sergey V Turchin на комментарий #75)
> Перед тем, как спросить я перечитал на всякий comment#0, но там нет вопросов.
> Предложение вернуться к обсуждению возможности запрета по умолчанию
> установки без пароля?

Да.

> 
> Я не против, но нужен ли вообще packagekit на этих системах?

На Рабочей станции? Да, нужен, для оффлайн-обновления, для установки приложений через gnome-software.

Ок. А зачем не давать локально залогиненому wheel-у устанавливать пакеты?
Не нашёл полезных поводов ни для дома ни для организации.

(Ответ для Sergey V Turchin на комментарий #77)
> Ок. А зачем не давать локально залогиненому wheel-у устанавливать пакеты?
> Не нашёл полезных поводов ни для дома ни для организации.

1. Потому что это должен делать root и пользователи, авторизующиеся как root.
2. Пользователь wheel, не зная пароля root, может установить пакет с правилом polkit, которое позволят ему ещё и удалять пакеты. И мало ли какое ещё правило polkit может быть собрано в репозитории. То есть разрешая ему ставить пакеты, мы открываем ему возможность расширять свои привилегии.
3. Пользователь wheel может установить пакеты, которые систему сломают.
4. Пользователь wheel может запустить недоверенный скрипт, который воспользуется возможностью установки пакетов без ввода пароля и откроет злоумышленнику доступ к системе.
5. Пользователь wheel может отойти от компьютера, забыв заблокировать сеанс. В результате облегчаем злоумышленнику задачу по получению доступа к системе.

То есть убираем потенциальную дыру в безопасности.
И наконец. Неужели сложно ввести пароль root при установке приложения?

> > Не нашёл полезных поводов ни для дома ни для организации.
> 
> 1. Потому что это должен
Я торжественно освобождаю всех от долгов. ;-)

По вышеперечисленному проблемы только на домашней системе, верно?

(Ответ для Sergey V Turchin на комментарий #79)
> > > Не нашёл полезных поводов ни для дома ни для организации.
> > 
> > 1. Потому что это должен
> Я торжественно освобождаю всех от долгов. ;-)
> 
> По вышеперечисленному проблемы только на домашней системе, верно?

Почему это?

(Ответ для Антон Мидюков на комментарий #78)
> это должен делать root и пользователи, авторизующиеся как root.
Это плохо. Вместо этого администратор работает не от root, а от простого пользователя, состоящего в группе wheel.

Достаточно не давать возможность при установке добавить 1-го пользователя в группу wheel.

(Ответ для Антон Мидюков на комментарий #80)
> > По вышеперечисленному проблемы только на домашней системе, верно?
> Почему это?
А откуда в организации взялись простые пользователи с такими возможностями?

(Ответ для Sergey V Turchin на комментарий #81)
> (Ответ для Антон Мидюков на комментарий #78)
> > это должен делать root и пользователи, авторизующиеся как root.
> Это плохо. Вместо этого администратор работает не от root, а от простого
> пользователя, состоящего в группе wheel.

Под "авторизующиеся как root" я имел в виду пользователей группы wheel, повышающие свои привилегии через polkit для конкретного действия - установки через packagekit. Администратор и работает как простой пользователь, но при необходимости выполнить установку пакетов вводит пароль root.
Поэтому это хорошо, а не плохо. В организациях вместо пароля root, могут настраивать ввод пароля пользователя группы wheel. Но это должны именно настроить. И почувствуйте разницу между установкой с вводом своего пароля и установкой без ввода пароля.

> 
> Достаточно не давать возможность при установке добавить 1-го пользователя в
> группу wheel.

Нет. Это вообще не имеет отношения к делу.

(Ответ для Sergey V Turchin на комментарий #82)
> (Ответ для Антон Мидюков на комментарий #80)
> > > По вышеперечисленному проблемы только на домашней системе, верно?
> > Почему это?
> А откуда в организации взялись простые пользователи с такими возможностями?

Очевидно, что это администраторы, а не простые пользователи.

(Ответ для Антон Мидюков на комментарий #84)
> > А откуда в организации взялись простые пользователи с такими возможностями?
> Очевидно, что это администраторы, а не простые пользователи.
Тогда всё в порядке. Они знают, что делают.

(Ответ для Антон Мидюков на комментарий #78)
> 5. Пользователь wheel может отойти от компьютера, забыв заблокировать сеанс.
Лошара, а не админ. :-)

(Ответ для Sergey V Turchin на комментарий #86)
> (Ответ для Антон Мидюков на комментарий #78)
> > 5. Пользователь wheel может отойти от компьютера, забыв заблокировать сеанс.
> Лошара, а не админ. :-)

Это называется человеческий фактор.

(Ответ для Антон Мидюков на комментарий #87)
> > > 5. Пользователь wheel может отойти от компьютера, забыв заблокировать сеанс.
> > Лошара, а не админ. :-)
> Это называется человеческий фактор.
Если официально в приказе на увольнение, то можно и так. ;-)

https://t.me/alt_linux/538149
Вот, например, решается удалением packagekit.

Но, если какой-нибудь alterator-components начнёт его использовать, то удаление станет невозможно.

(Ответ для Sergey V Turchin на комментарий #89)
> https://t.me/alt_linux/538149
> Вот, например, решается удалением packagekit.

Можно не заметить, как packagekit залетит при обновлении.
Из коробки гайки должны быть завинчены. Бага именно об этом.

(Ответ для Sergey V Turchin на комментарий #9)
> В принципе, я не против отдельного пакета.

Мне достаточно будет, если я не пропущу его прохождение в p11.

(Ответ для 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 на новый пакет вместо этого.

(Ответ для Антон Мидюков на комментарий #93)
> Поставь зависимость у пакета alt-kworkstation-addon на новый пакет вместо
> этого.
Само собой. Я лишь хочу, чтобы они в один день провалились в p11.

Бага будет исправляться?

packagekit 1.3.0-alt5

(Ответ для Sergey V Turchin на комментарий #96)
> packagekit 1.3.0-alt5

Спасибо!