Непонятно, почему localadmin стал пользователем по умолчанию для всех случаев установки. Из описания в приложении непонятно, что делает галочка с первым пользователем - администратором и что будет если её снять. Поэтому хочется вернуть умолчание на старое поведение, а галочку хорошо расшифровать прямо в форме.
localadmin по умолчанию это идея Евгения sin@. Я её только реализовал, как мог. Вопрос "почему" переадресую Евгению. Галочка делает простую вещь - заполняет поля формы некоторыми значениями. Её снятие, соответственно - просто очищает поля формы. Описание "Задать имя пользователя по умолчанию для локального администратора" сделано в предположении, что 1-й обычный пользователь, создаваемый при установке и есть локальный администратор. Если есть предложения, как описать эту функцию лучше, давайте обсудим их в данной баге.
да, ошибка была для этого и создана, что бы данная "фича" стала понятнее. Во первых было бы интересно узнать, зачем она нужна. Во вторых - галочку я бы переделал в "Имя по умолчанию для первого пользователя". Потому что сейчас возникает ощущение что помимо имени эта галочка влияет ещё на что-то (группу wheel, например). И это серьёзно вводить в заблуждение. Вплоть до претензий в том, что первый пользователь имеет права рута.
(Ответ для Anton Farygin на комментарий #2) > да, ошибка была для этого и создана, что бы данная "фича" стала понятнее. > > Во первых было бы интересно узнать, зачем она нужна. > Во вторых - галочку я бы переделал в "Имя по умолчанию для первого > пользователя". > > Потому что сейчас возникает ощущение что помимо имени эта галочка влияет ещё > на что-то (группу wheel, например). И это серьёзно вводить в заблуждение. > Вплоть до претензий в том, что первый пользователь имеет права рута. 1-й пользователь по умолчанию входит в группу wheel и потому фактически является локальным администратором. От состояния галочки это не зависит. И описание галочки это показывает: она не меняет его права, она только предлагает имя, соответствующее этим правам. Можно уточнить описание так: "Задать имя по умолчанию для первого пользователя, который является локальным администратором"
(In reply to jqt4@altlinux.org from comment #3) > Можно уточнить описание так: > "Задать имя по умолчанию для первого пользователя, который является > локальным администратором" Да, это ещё один из вариантов. Но если пойти дальше, то я бы переформатировал шаг ещё дальше. 1) Добавить галочку "имеет право перехода в режим администратора" вместо "имя по умолчанию". Включенную по умолчанию, естественно (что бы поведение не менялось). Галочка влияет на группы первого пользователя, т.к. есть убеждение что не во всех конфигурациях системы первого пользователя нужно добавть в группу wheel и давать ему расширенные права. 2) вместо галочки, которая заполняет localadmin - сделать кнопку - "заполнить автоматически", которое собственно и заполнит в localadmin и включит (если выключена) галочку. Но вообще идея называть первого пользователя всегда localadmin выглядит очёнь стрёмно и путает народ, т.к. по факту из его прав администратора только дополнительные группы.
Может, просто одну галочку "Есть переход на сисадмина" и при включенной делать имя "localadmin"? Оно же остаётся редактируемым. Можно ещё сменить "localadmin" на что-то. "wheeluser", "wheely" или ещё что-то придумать похожее на недоадмина.
(Ответ для Sergey V Turchin на комментарий #5) > Может, просто одну галочку "Есть переход на сисадмина" и при включенной > делать имя "localadmin"? > Оно же остаётся редактируемым. Практически так и сделано в задаче #369411: подробно описано что происходит: "Cоздание учетной записи системного пользователя с правом повышения привилегий" "По умолчанию используется имя localadmin." "Имя localadmin стандартизирует учетные записи локальных администраторов и упрощает диагностику в корпоративной среде." подпись у галочки просто "Задать имя пользователя по умолчанию", специально убрано всякое упоминание сисадмина, чтобы меньше пугало. > > Можно ещё сменить "localadmin" на что-то. "wheeluser", "wheely" или ещё > что-то придумать похожее на недоадмина.
(Ответ для jqt4@altlinux.org на комментарий #6) > подпись у галочки просто "Задать имя пользователя по умолчанию", специально > убрано всякое упоминание сисадмина, чтобы меньше пугало. Не убрано, а добавлено. Раньше никакого "admin" или "админ" там не было.
(Ответ для Sergey V Turchin на комментарий #7) > (Ответ для jqt4@altlinux.org на комментарий #6) > > подпись у галочки просто "Задать имя пользователя по умолчанию", специально > > убрано всякое упоминание сисадмина, чтобы меньше пугало. > Не убрано, а добавлено. Раньше никакого "admin" или "админ" там не было. Не понял, что имеется в виду. Я писал о том, что подпись галочки "Задать имя пользователя по умолчанию для локального администратора" исправлена на "Задать имя пользователя по умолчанию"
(Ответ для jqt4@altlinux.org на комментарий #8) > > Не убрано, а добавлено. Раньше никакого "admin" или "админ" там не было. > Не понял, что имеется в виду. Теперь там написано "localADMIN".
alterator-users-10.24-alt4 -> sisyphus: Mon Jan 13 2025 Dmitry Terekhin <jqt4@altlinux> 10.24-alt4 - Clarify description and fix GECOS for localadmin (ALT #52476)
(Ответ для Repository Robot на комментарий #10) > localadmin Назвали бы сразу lamer. Зачем так завуалировано? Всё равно все догадаются, что "админ локалхоста" ;-)
(Ответ для jqt4@altlinux.org на комментарий #8) > > > убрано всякое упоминание сисадмина, чтобы меньше пугало. > > Не убрано, а добавлено. Раньше никакого "admin" или "админ" там не было. > Не понял, что имеется в виду. Там же русским по белому написано "Администратор". Зачем пугать?
(Ответ для Sergey V Turchin на комментарий #11) > (Ответ для Repository Robot на комментарий #10) > > localadmin > Назвали бы сразу lamer. Зачем так завуалировано? Всё равно все догадаются, > что "админ локалхоста" ;-) Если постараться уйти от технического снобизма админов локалхоста, которые всех называют ламерами, то цель одного общего пользователя localadmin вполне понятна и ценна. На 10 тысячах машин иметь 10 тысяч разных локальных админов не имеет смысла. Под такими машинами, вообще, под локальными пользователями не работают. Но этой проблемы не видно админам локалхостов. В качестве рекомендации я бы её оставил по умолчанию, а в частном порядке всегда можно задать любое другое имя. Никого это путать не должно. "Админом" называют разные сущности: 1) Просто пользователя root. Хотя обычно его называют супер-пользователем. В NT - это пользователь System. Во всех и линуксовых, и виндовых рекомендациях под таким пользователем работать не рекомендуется. В том числе и для административных задач. 2) Пользователь, которому предоставляется право на повышение привилегий. Такой "Админ" зазаётся через группу wheel, а также через AdminRule в PolicyKit. Для polkit-правил "Админ" - это глобальная роль. И пользователь, который играет эту роль и есть Локалльный администратор. Добавлять сразу и рабочего пользователя, не имеющего прав на повышение привилегий можно, но такой пользователь не будет интересен. В общем кейсы нужно разобрать поподробнее. Явной проблемы в текущей реализации пока не прослеживается.
(Ответ для Evgeny Sinelnikov на комментарий #13) > Если постараться уйти от технического снобизма админов локалхоста, которые > всех называют ламерами Подтасовка понятий лишь разваливает вашу аргументацию. Это ваша идея -- обозвать 1-го(а иногда единственного) пользователя админом локалхоста буквально. > В качестве рекомендации я бы её оставил по умолчанию Вот и переместите её из реализации в рекомендацию. ;-) > "Админом" называют разные сущности: Вот именно! Не стоит путать пользователя. > Явной проблемы в текущей реализации пока не прослеживается. Было бы странно, если бы автор идеи сам прослеживал и искал аргументы против себя.
Предлагаю компромиссный вариант: 1. Галочка не активирована по дефолту 2. Страшная надпись в последнем релизе уходит в справку 3. Пользователю возвращаем его изначальный статус "Системный пользователь" - он никакой не администратор (по дефолту).
(Ответ для Антон Мидюков на комментарий #15) > Предлагаю компромиссный вариант: > 1. Галочка не активирована по дефолту > 2. Страшная надпись в последнем релизе уходит в справку > 3. Пользователю возвращаем его изначальный статус "Системный пользователь" - > он никакой не администратор (по дефолту). В целом, пока пойдёт, но есть ещё одно дополнение. В зависимости от редакции, выбираемой на стадии установки данное поведение можно будет задавать. Но об этом нужно ещё подумать. ___________ Ещё раз про администраторов локальных узлов. Кто такой "админ локалхоста"? В смысле удалённого или локального логина - это не root. Супер-пользователь у нас, да и в некоторых, других дистрах - это, скорее, привилегия, доступ к которой требует отдельного пароля. В систему под рутом, тем более в графику, никто не ходит. Так что root, в этом смысле, для пользователя вовсе и не пользователь, только технически. На сервера, в некоторых случаях ходят в рута по ключу, но это другая история. Пользователь же - это тот субъект безопасности, от имени которого запускается сессия. А администратор - это именно тот пользователь, который администрирует (или имеет на это право) данный хост. В этом смысле первый (а иногда и единственный) пользователь, входящий в группу wheel, есть никто иной, как пользователь играющий роль администратора. И, по умолчанию, ему необходимо помнить два пароля в наших, текущих дефолтах - свой и рутовый. В корпоративной среде для машины в домене пароль рута на каждой машине администратор рабочих станций может вообще не знать. Да и не должен. В этом смысле права локального админа - это есть право на запуск sudo или действия контролируемого polkit-ом. Право на запуск su - без пароля рута оказываются недоступны. То есть, для машины в домене именно так и требуется - "обозвать 1-го (а иногда единственного) пользователя админом локалхоста буквально." По сути, он такую роль и играет, как локальный пользователь, поскольку если не поставить в текущем альтераторе при создании пользователя галочку "администратор" (замечу, тоже буквально), то он не войдёт в группу wheel, не сможет запускать, ни su -, ни sudo, ни действий через polkit, даже при наличии дефолтного правила из пакета polkit-default-rules. Типичная ситуация: - вводим машину в домен; - создаём обычного пользователя без группы wheel; - логинимся и понимаем, что ничего сделать нельзя (а это могут более 90% пользователей); - создаём пользователя с доменной группой workstation-administrators; - добавляем политикой через модуль ролей доменной группе workstation-administrators группу wheel (на freeipa можно напрямую, без промежуточной группы-роли, хотя и не стоит); - получаем группу локальных администраторов, которые могут сделать хоть что-то, что тоже можно контролировать через правила sudo или polkit-правила. Рассчитывать что все пользователи из группы workstation-administrators будут знать пароль рута на каждой из тысяч машин можно только в том случае, когда эти пароли централизованно задаются, регулярно меняются и централизованно же могут быть получены пользователями из групп workstation-administrators или domain-administrators. В этом смысле называть привилегию пользователя root, локальным администратором, как минимум, спорная история. Называть же первого пользователя в системе, по умолчанию, вполне разумно. Всегда можно дат при установке другое имя. Не вижу никакой проблемы. Никто же это возможность не убирал и убирать не собирался. Итого, дефолты, в зависимости от масштабирования необходимы разные.
В домашнем сценарии этот же пользователь и админ по умолчанию. В офисных сценариях (с доменами) первый пользователь и не пользователь по умолчанию (и не админ). В целом текущее поведение (которое было в десятой линейке) выглядит хорошо, не вижу никакого смысла его менять.
"Страшная надпись в последнем релизе". В контексте предоставления привилегий локальный администратор - это, по сути, такой пользователь, который: 1) входит в группу wheel; и 2.1) либо знает пароль рута; 2.2) либо для него, через группу wheel, включены дефолтные правила sudo и polkit. Но ключевым является вхождение в группу wheel. Пользователя с такой привилегией можно называть: - либо "Локальным администратором"; - либо "Пользователем с правом повышения привилегий". Что, в таком случае "страшного" в надписи "в последнем релизе"? +msgid "Creates a system user account with privilege escalation rights" +msgstr "Cоздание учетной записи системного пользователя с правом повышения привилегий" Меня смущает только слово "системный". В Gnome так об этом и указано в документации: - https://help.gnome.org/users/gnome-help/stable/user-accounts.html.en#privileges "You can allow users to make changes to the system by giving them administrative privileges." - https://help.gnome.org/users/gnome-help/stable/user-admin-explain.html.en "Administrative privileges are associated with your user account. Administrator users are allowed to have these privileges while Standard users are not." А первый пользователь всегда, как раз, и создаётся с такими привилегиями.
Системный пользователь - это общепринятое название пользователя для системных процессов. Должно быть создание обычного пользователя.
(Ответ для Anton Farygin на комментарий #17) > В офисных сценариях (с доменами) первый пользователь и не пользователь по > умолчанию (и не админ). А кто он? Группа wheel ему задаётся. Правила sudo и polkit в домене, скорее всего, будут включены. С его паролем вполне можно будет логинится и администрировать. Не вижу смысла называть его никем, кроме localadmin или чем-то подобным. Это его дефолтное поведение в домене. Если доступ к домену отваливается по кем заходить? Ну, вот под этим первым локальным админом только и можно будет.
(Ответ для Anton Farygin на комментарий #19) > Системный пользователь - это общепринятое название пользователя для > системных процессов. Это да. > Должно быть создание обычного пользователя. По группе wheel - нет.
(In reply to Evgeny Sinelnikov from comment #21) > (Ответ для Anton Farygin на комментарий #19) > > Системный пользователь - это общепринятое название пользователя для > > системных процессов. > > Это да. > > > Должно быть создание обычного пользователя. > > По группе wheel - нет. В группе wheel - да.
(In reply to Evgeny Sinelnikov from comment #20) > (Ответ для Anton Farygin на комментарий #17) > > В офисных сценариях (с доменами) первый пользователь и не пользователь по > > умолчанию (и не админ). > > А кто он? Группа wheel ему задаётся. Правила sudo и polkit в домене, скорее > всего, будут включены. С его паролем вполне можно будет логинится и > администрировать. > > Не вижу смысла называть его никем, кроме localadmin или чем-то подобным. > Это его дефолтное поведение в домене. Ну ровно так же его можно назвать firstuser, specialuser, adminuser и любым другим именем, которое придумает системный администратор. Откуда вообще возникла такая потребность дать какое-то специальное имя первому пользователю ? Я не вижу ни одного запроса по этому поводу. А ломать действующую систему не надо. > > Если доступ к домену отваливается по кем заходить? Ну, вот под этим первым > локальным админом только и можно будет. А что делать если домена нет вовсе ? Какое количество наших пользователей используют систему именно в такой конфигурации ? Опять же - сколько у меня было вопросов к домену - всегда вход рутом на локальной консоли (в терминале) или по ssh по ключу. Тот, кому нужно это сделать - даст нужное ему имя локальному пользователю через доменную политику. Мы же можем сделать так, что бы при вводе в домен прилетала политика, которая заводит пользователя localadmin с нужными привелегиями ?
Created attachment 17543 [details] Входит в группу администраторов "Входит в группу администраторов" означает входит в группу wheel. Это исходное состояние в настройках. Первый пользователь входит в группу wheel. Кто такой первый пользователь?
(Ответ для Evgeny Sinelnikov на комментарий #13) >Что, в таком случае "страшного" в надписи "в последнем релизе"? Некрасиво делать такой текст вот так, как сделали (кусок текста). Для этого есть справка. Надписи в интерфейсе должны быть лаконичными.
Выключи режим эксперта, не нужно это. 1) мы же сейчас говорим про программу установки, а не про альтератор. 2) wheel в нашей конфигурации даёт право выполнять su (sudo если настроить) и устанавливать пакеты через polkit - это не значит что этот пользователь админ. Более того - многие уверены, что polkit использует wheel неправильно и это поведение надо изменить, добавив специальные группы для его действий. Разумнее было бы добавить группу localadmin и через неё управлять возможностью эскалировать привилегии для некоторых операций.
(Ответ для Anton Farygin на комментарий #23) [...] > > А что делать если домена нет вовсе ? > Какое количество наших пользователей используют систему именно в такой > конфигурации ? Текущее предложение от Антона Мидюкова вполне подходит. Особенно, если в редакции для корпоративных пользователей дефолты буду соответствующие. А для тех, у кого домена нет - будут, как обычно, придумывать своё любимое или тыкать, наобум, как придётся. А потом их будут ламерами "обзывать". Я не понимаю проблемы дефолта. Чем он помешал? Но решили, что в редакции для физиков, можно дефолтную рекомендацию требовать включить явно. То есть галочку отключить. > Опять же - сколько у меня было вопросов к домену - всегда вход рутом на > локальной консоли (в терминале) или по ssh по ключу. На каждую рабочую станцию? Куче разных людей? Ну, так себе история. > Тот, кому нужно это сделать - даст нужное ему имя локальному пользователю > через доменную политику. Политики применяются после: - установки машины; - настройки сети; - введения в домен. Все эти действия делаются под первым пользователем, которым устанавливал машину - внимание, "локальным администратором" или пользователем "с правом повышения привилегий". > Мы же можем сделать так, что бы при вводе в домен прилетала политика, > которая заводит пользователя localadmin с нужными привелегиями ? Не в этом цель. Цель в дефолтных рекомендациях. Для того, чтобы машину ввести, нужно сначала на неё под кем-то залогиниться.
(In reply to Evgeny Sinelnikov from comment #27) > Я не понимаю проблемы дефолта. Чем он помешал? Но решили, что в редакции для > физиков, можно дефолтную рекомендацию требовать включить явно. То есть > галочку отключить. Её во всех редакциях надо выключить. А если быть точнее - такая галочка и вовсе не нужна. > > > Опять же - сколько у меня было вопросов к домену - всегда вход рутом на > > локальной консоли (в терминале) или по ssh по ключу. > > На каждую рабочую станцию? Куче разных людей? Ну, так себе история. Ты же в домене, в корпоративной сети - у тебя есть сотни разных инструментов для решения этой задачи. Ты же не собираешься бегать по каждой стации и входить на ней localadmin что бы выполнить задачи администрирования ? > > > Тот, кому нужно это сделать - даст нужное ему имя локальному пользователю > > через доменную политику. > > Политики применяются после: > - установки машины; > - настройки сети; > - введения в домен. > > Все эти действия делаются под первым пользователем, которым устанавливал > машину - внимание, "локальным администратором" или пользователем "с правом > повышения привилегий". Не обязательно. Сеть можно настроить на этапе установки машины и до входа в систему. А в домен можно войти из консоли. Лучше вместо придумывания несуществующих сценариев заняться инструментами для автоматизации вот этих этапов. > > > Мы же можем сделать так, что бы при вводе в домен прилетала политика, > > которая заводит пользователя localadmin с нужными привелегиями ? > > Не в этом цель. Цель в дефолтных рекомендациях. > Для того, чтобы машину ввести, нужно сначала на неё под кем-то залогиниться. Точно ? А можно ли ввести машину в домен заранее, до момента её включения ?
(Ответ для Anton Farygin на комментарий #26) > Выключи режим эксперта, не нужно это. > > 1) мы же сейчас говорим про программу установки, а не про альтератор. В этом контексте мы говорим о том, кого, вообще, мы называем "Локальным администратором". Показываю, что единственное, что в текущей системе старые модули Альтератора называют "Входит в группу администраторов" означает входит в группу wheel. То есть входить в группу и wheel и быть локальным администратором, при знании пароля рута - это одно и то же. В любом случае это право (то есть возможность) "повышения привилегий". > 2) wheel в нашей конфигурации даёт право выполнять su (sudo если настроить) > и устанавливать пакеты через polkit - это не значит что этот пользователь > админ. А что значит формально быть или не быть админом? Знание пароля рута - не формальный критерий. Группа wheel - формальный. Не входя в группу wheel, знание пароля рута не всегда поможет поднять привилегии. Хотя ожно через текстовую консоль, или через что-то забыли открутить. > Более того - многие уверены, что polkit использует wheel неправильно и это > поведение надо изменить, добавив специальные группы для его действий. Да, согласен. > Разумнее было бы добавить группу localadmin и через неё управлять > возможностью эскалировать привилегии для некоторых операций. Такая группа уже есть - называется localadmins: $ grep localadmins /etc/group localadmins:x:101:sin,iv
(In reply to Evgeny Sinelnikov from comment #29) > > Разумнее было бы добавить группу localadmin и через неё управлять > > возможностью эскалировать привилегии для некоторых операций. > > Такая группа уже есть - называется localadmins: > $ grep localadmins /etc/group > localadmins:x:101:sin,iv Тогда нужно изменить поведение: - на этапе установки системы первому пользователю сделать галочку (включенную по умолчанию) - входит в группу администраторов В справке указать что пользователь будет входить в группу wheel и localadmins В polkit сменить wheel на localadmins для установки и обновления. Имя пользователя по умолчанию не делать, и проработать вариант с автоматизацией ввода машины в домен после клонирования (в Windows же есть подобный инструмент?)
(Ответ для Anton Farygin на комментарий #28) > (In reply to Evgeny Sinelnikov from comment #27) [...] > > > Опять же - сколько у меня было вопросов к домену - всегда вход рутом на > > > локальной консоли (в терминале) или по ssh по ключу. > > > > На каждую рабочую станцию? Куче разных людей? Ну, так себе история. > > Ты же в домене, в корпоративной сети - у тебя есть сотни разных инструментов > для решения этой задачи. Ты же не собираешься бегать по каждой стации и > входить на ней localadmin что бы выполнить задачи администрирования ? В домене идёт регулярная эксплуатация. И её качество зависит от предусмотренных возможностей. В частности, сеть иногда отваливается, из домена машина может вылететь по разным причинам... И локальный пользователь для таких ситуаций должен быть предусмотрен. > > > > > Тот, кому нужно это сделать - даст нужное ему имя локальному пользователю > > > через доменную политику. > > > > Политики применяются после: > > - установки машины; > > - настройки сети; > > - введения в домен. > > > > Все эти действия делаются под первым пользователем, которым устанавливал > > машину - внимание, "локальным администратором" или пользователем "с правом > > повышения привилегий". > > Не обязательно. Сеть можно настроить на этапе установки машины и до входа в > систему. А в домен можно войти из консоли. > > Лучше вместо придумывания несуществующих сценариев заняться инструментами > для автоматизации вот этих этапов. Нет это не придумывание. Это опыт эксплуатации, который в текущей задаче описать во всех деталях проблематично. Часть деталей я излагаю, часть этих деталей субъективна... Впрочем, как и многие другие "дефолты" во многих наших пакетах. > > > > > Мы же можем сделать так, что бы при вводе в домен прилетала политика, > > > которая заводит пользователя localadmin с нужными привелегиями ? > > > > Не в этом цель. Цель в дефолтных рекомендациях. > > Для того, чтобы машину ввести, нужно сначала на неё под кем-то залогиниться. > > Точно ? > А можно ли ввести машину в домен заранее, до момента её включения ? Технологии имеются, но сделать быстро их удобными - это сложная история: - https://www.samba.org/~gd/slides/Join%20me%20offline!.pdf К тому же все админы консервативны и к рискам апробации на себе относятся негативно. На практике есть множество проблем с этой историей пока. К вопросу о дефолтной рекомендации про localadmin это никак не относится. Зайти локальным пользователем бывает нужно. В рута для множества задач заходить не имеет смысла. Да и пароль всем шарить - не вариант. LAPSv2 в проработке. Но этот вопрос, он тоже не закрывает.
ну мне кажется мы друг-друга поняли. осталось только сделать так, что бы у нас не было "стандартного" имени пользователя для администратора с возможностью удалённого входа. В том числе с точки зрения безопасности системы.
(Ответ для Anton Farygin на комментарий #30) > (In reply to Evgeny Sinelnikov from comment #29) > > > Разумнее было бы добавить группу localadmin и через неё управлять > > > возможностью эскалировать привилегии для некоторых операций. > > > > Такая группа уже есть - называется localadmins: > > $ grep localadmins /etc/group > > localadmins:x:101:sin,iv > > Тогда нужно изменить поведение: > - на этапе установки системы первому пользователю сделать галочку > (включенную по умолчанию) - входит в группу администраторов > В справке указать что пользователь будет входить в группу wheel и localadmins > В polkit сменить wheel на localadmins для установки и обновления. > > Имя пользователя по умолчанию не делать, и проработать вариант с > автоматизацией ввода машины в домен после клонирования (в Windows же есть > подобный инструмент?) В Windows? В Windows много лет есть Локальный администратора в виде всем известного первого пользователя "Администратор" со свои предзаданным значением S-1-5-21domain-500 (Well-known Security Identifiers) в каждом домене, в том числе и локальном. Но мы разные кейсы рассматриваем. В ручном режиме возможности тоже должны быть проработаны. Именно с ними сталкиваются при первичном развертывании и знакомстве. Инфраструктура появляется позже. А десятки невнятных первичных установок так болтаются со своими оригинальными настройками в рамках личных предпочтений и накапливаются в рамках каждого нового админа. "Автоматизацией ввода машины в домен после клонирования" - это другая задача. Какое в ней предлагается по рекомендации имя первого пользователя. Сколько образов, столько и имён?
(Ответ для Anton Farygin на комментарий #32) > ну мне кажется мы друг-друга поняли. > осталось только сделать так, что бы у нас не было "стандартного" имени > пользователя для администратора с возможностью удалённого входа. > > В том числе с точки зрения безопасности системы. Да, это вопрос самый разумный во всём обсуждении.
(Ответ для Evgeny Sinelnikov на комментарий #27) > А потом их будут ламерами "обзывать". Я понимаю, что автор обсуждаемого изменения сам хотел и сразу, но, уверен, не стоит. ;-)
(Ответ для Evgeny Sinelnikov на комментарий #34) > > В том числе с точки зрения безопасности системы. > Да, это вопрос самый разумный во всём обсуждении. Разумнее только изначально не придумывать ухудшений безопасности на ровном месте типа идеи отключения обновления пакетов. Полагаю, в запасе ещё не одна есть. ;-) P.S. В других системах есть автоматическая генерация имени пользователя на основе реального имени. Попробуйте реализовать, раз уж есть желание.
(Ответ для Sergey V Turchin на комментарий #36) > (Ответ для Evgeny Sinelnikov на комментарий #34) > > > В том числе с точки зрения безопасности системы. > > Да, это вопрос самый разумный во всём обсуждении. > Разумнее только изначально не придумывать ухудшений безопасности на ровном > месте типа идеи отключения обновления пакетов. Полагаю, в запасе ещё не одна > есть. ;-) Не стоит мешать всё в одну кучу. К этому вопросу мы тоже ещё вернёмся. Особенно, с того момента, когда начнём разбирать двусмысленную природу продукта, как целостного набора пакетов конкретных версий в образе и как набора пакетов из обновлений, которые никогда не должны ломаться, но почему-то всё время в этом не идеальном мире ломаются. Никогда речь не шла об отключении обновлений. Речь шла о тестировании очередного среза и обеспечении предсказуемых обновлений в рамках срезов доступных через архив. > P.S. В других системах есть автоматическая генерация имени пользователя на > основе реального имени. Попробуйте реализовать, раз уж есть желание. В такой форме это никому не нужно. В рамках конкретной инфраструктуры есть потребность фиксировать шаблоны развёртывания. Вместо localdomain имя пользователя можно задавать через инфраструктуру. Идея - вводить для этого машину у домен кажется слишком избыточной. Такая потребность возникает для большого числа типовых узлов не только в рамках доменов. Задача шаблонизации таких настроек в рамках инфраструктуры, предварительно, предполагает наличие таких настроек. Иначе нечего будет шаблонизировать.
(Ответ для Evgeny Sinelnikov на комментарий #37) > Никогда речь не шла об отключении обновлений. Записал в блокнотик. ;-) > > P.S. В других системах есть автоматическая генерация имени пользователя на > > основе реального имени. Попробуйте реализовать, раз уж есть желание. > В такой форме это никому не нужно. Исходя из этой фразы оно ровно также не нужно в любой текущей форме, т.к. не фиксированное. > В рамках конкретной инфраструктуры есть потребность фиксировать шаблоны развёртывания. Видимо, фиксировать надо в шаблонах, а не при установке, добавляя пользователю ненужную функциональность. Т.е. фиксировать за пределами GUI установщика. P.S. Было обсуждение файла конфигурации. В зависимости от него можно вообще залочить имя пользователя от редактирования, если вам нужно фиксированное.
(Ответ для Evgeny Sinelnikov на комментарий #37) > набора пакетов из обновлений, которые никогда не должны ломаться, но > почему-то всё время в этом не идеальном мире ломаются. Звучало же предложение по созданию бранча-кэша обновлений для дополнительной обкатки. Я не в курсе продолжения.
(Ответ для jqt4@altlinux.org на комментарий #1) > localadmin по умолчанию это идея Евгения sin@. Очень плохая идея, сломавшая хороший модуль, созданный для других задач. Как отметил в переписке: --- Ну и я пока так и не понял, с какого перепугу и кто именно решил, что дефолтный пользователь с доп. правами в *корпоративной* среде -- это вообще хорошая мысль. Да, для техподдержки может быть проще сказать "зайдите вот этим" вместо "зайдите тем, кого заводили первым" -- вот только для атак удобство тоже возрастает, а сделать с этим что-либо вполедствии будет куда тяжелей. И это, кстати, очень характерное свойство простых, понятных, неправильных решений. --- Там же привёл намётку _возможно_ более разумного варианта, см. тему "механизм выработки целеполагания" по словам "профилирующий пакет". (Ответ для Sergey V Turchin на комментарий #11) > Назвали бы сразу lamer. Зачем так завуалировано? > Всё равно все догадаются, что "админ локалхоста" ;-) Как автор термина не припоминаю такого подтекста -- скорее было про малозначимость сопровождаемых таким человеком (мной, в частности :) систем. Перекликалось с диалогом то ли на ЛОРе, то ли на опеннете, то ли у нас где: "спросили пароль root, ввёл, теперь [root@localhost #] и курсор мигает, что дальше делать?" -- "ну как что, теперь ты рут, теперь ты крут!.." (Ответ для Evgeny Sinelnikov на комментарий #13) > На 10 тысячах машин иметь 10 тысяч разных локальных админов не имеет смысла. > Под такими машинами, вообще, под локальными пользователями не работают. Значит, там не нужен alterator-users при установке или вообще. > Но этой проблемы не видно админам локалхостов. А этой? > В NT - это пользователь System. Хватит делать из линукса винду, здесь от одной красной шляпы на пустом жбане хватает головной боли более чем (тот недоумок, которому сунули в руки polkit, прекрасно это проиллюстрировал несколько лет назад, породив пару знатных CVE). > 2) Пользователь, которому предоставляется право на повышение привилегий. > Такой "Админ" зазаётся через группу wheel, а также через AdminRule в > PolicyKit. Для polkit-правил "Админ" - это глобальная роль. И пользователь, > который играет эту роль и есть Локалльный администратор. В owl/alt последние лет двадцать рекомендуется применять ssh по ключу непосредственно по имени root для получения полных административных привилегий; некоторые так ходят с localhost, чтобы централизовать механизм получения таковых и не держать su вообще или в отличном от restricted состоянии control(8). Тащить лишний раз polkit в эти вопросы и тем более закладываться на него считаю признаком глубокой профнепригодности (по причине профнепригодности архитекторов и реализаторов этого поделия, см. опять же историю уязвимостей в деталях). Некоторые делают дублированные аккаунты с uid/gid 0 (классический пример -- toor); не уверен, что этот подход стоит дистрибутивизации, поскольку как минимум принцип наименьшего удивления он нарушает. > Добавлять сразу и рабочего пользователя, не имеющего прав на повышение > привилегий можно, но такой пользователь не будет интересен. Это в твоей сугубо доменной парадигме, на которую alterator-users попросту не рассчитан (вплоть до того, что в ней он не нужен, если не применяется для взаимодействия с доменом через тот же PAM). > В общем кейсы нужно разобрать поподробнее. > Явной проблемы в текущей реализации пока не прослеживается. Это для тебя. Обсуждение давайте продолжим, а http://git.altlinux.org/tasks/370597/ с откатом этого безобразия (желающие могут подать на CVE) отправил в сизиф. PS 2 jqt4: в будущем прошу обратить внимание и на то, что Release: -- это изменения в спеке и патчах; изменения кода -- это Version: (формально содеянное можно рассматривать как попытку спрятать вредоносное изменение в "незначительной" сборке, хотя понятно, что злого умысла тут не было). PPS (Ответ для Evgeny Sinelnikov на комментарий #16) > Называть же первого пользователя в системе, по умолчанию, вполне разумно. > Всегда можно дат при установке другое имя. Не вижу никакой проблемы. Never underestimate the power of the default (c) malx Ты не видишь -- не значит, что проблемы нет. Широко известный логин с дополнительными правами -- это проблема. Причём класса "заложенная большевиками под Россию мина <<коренизации>>".
Отдельным комментарием: если в каком-либо дистрибутиве/режиме вам не нужен alterator-users -- просто не ставьте его.
