>> Странно
>ничего странного - большинство людей, вот удивительно-то, на работу ходят - работать.
>Остальных увольняют обычно еще до конца испытательного срока.Не вижу связи с темой обсуждения
>> Давать права локальных админов == root и червяки у Вас должны уже вчера бегать.
>у нас не бегали - что мы делали не так? (а когда всех принудительно привели к счастью - я побыстрее свалил, не дожидаясь приключений - и правильно сделал, как показало время)
>> Разграничить дополнительные права в линуксе ничуть не сложнее чем в винде, даже немного проще местами.
>ну вот и начнем с самого простого - пароль рута/эквивалентного ему юзера не должен быть root.
>И r00t тоже нехорошо, а вообще-то у червяка там некислый такой набор - довольно и непростые ухитряется подбирать. И?
Главная ошибка, что Вы считаете, что пользователю надо давать root. А это не так. У меня даже админы оракла, которые тоже админы, причем грамотные и сидящие в одной со мной комнате рута не имели. И единственное зачем он был им нужен это при установке апдейта запустить скрипт раздающий права (автоматически генерится инсталером). И да я не ленился запускать этот скрипт. Да я читал его только в первый раз. А потом выполнял не глядя. Но я знал кто мне его прислал и что этот человек не будет намерено дописывать в этот скрипт невесть что.
Все остальное, в том числе управление оракловыми пакетами в кластере, делалось ими через sudo.
И набор команд sudo был сильно ограничен. А для дежурных админов он был еще более ограничен.
Но при этом им всем хватало прав.
Что будет делать Ваш червяк в таком случае?
Кстати доступ по ssh для root во многих дистрах запрещен по умолчанию. О каких червях речь?
Вот на Винде мы специально политику делали запрещающую доступ локальному Администратору по сети.
>> Хотя может все дело в слове легально
>ну хотя бы беспалевно - можно, конечно, перехватить ветку регистри и принудительно там поменять параметры, даже те, которые назначаются политикой и локальным админам недоступны, но там есть аудит.
Все просто. На ветку регистри меняете права, что их писать не может никто кроме Вас. Пишите туда что Вам надо. И живете совершенно спокойно. И да, всяких домен админов тоже выкинуть из админов не сложно.
А аудит, ну и что? Кто будет этот лог читать? Со всех рабочих станций. И в зависимости от того какой метод сбора аудита настроен, если настроен, то запретить до логов достучаться тоже можно.
>В любом случае это требует навыков существенно больше чем у типичного power user, которым является у нас любой разработчик, к примеру. А вот passwd от root набрать если от обычного юзера он выпендривается - это они сумеют.
Так если они power user, то и не надо им root давать. Причем если в винде без root им сложно, т.к. часто софт не ставится. То дать права на yum install нет проблем. Вот только репозитарии они править не смогут. А из моего репо ставь что хочешь.
>впрочем, есть еще и smbpasswd, он в последних версиях и не выпендривается, и заодно, для вашего большего удобства, принудительно и неотключаемо синхронизирует пароль с системным ;-)
>Многие ли power users бросятся после этого его менять на безопасный?
При чем здесь smbpasswd? Если Вам так нужна интеграция с существующим АД, то тоже не вопрос.
Я на своем АРМ ходил к виндовым ресурсам по kerberos. В систему логинился под локальным юзером (ну параноя у меня такая), а потом получал тикет. Меня не напрягало ввести 2 пароля утром, а не один. Коллега так не парился. Логинился прямо на линукс с доменной учеткой. И политика на УЗ действовала доменная.
А если внедрять чисто линуксовое окружение, то и там УЗ будут от какого-то лдап/386, с соответствующей политикой.
А локальный root уж какой сделаете. У нас на каждом АРМ генерился пароль Администратора уникальный. И SCCM менял его раз в месяц. А техподдержка ходила к специальному серверу и запрашивала текущий пароль, когда он им был нужен. И потом всегда можно было узнать кто получал пароль Адимнистратора от такого-то АРМ.
Что мешает сделать что-то похожее на ansible/puppet? Схема от виндовой принципиально не отличается.
