В Срд, 10/12/2008 в 12:31 +0300, Artem Chuprina пишет: > Покотиленко Костик -> [email protected] @ Wed, 10 Dec 2008 > 10:47:01 +0200: > > >> >> > Как бы админ не хитрил с таймаутами, если в sudoers разрешен ALL, то > >> >> > никакого выигрыша от неиспользования root password мы не получим. > >> >> > >> >> Получим. Если у нас имеется несколько юзеров, которым разрешено sudo > >> >> ALL, то при увольнении одного из них нужно только deluser сделать. > >> >> А если бы использовалось su, то пришлось бы менять рутовый пароль и > всем > >> >> остальным админам заучивать новый. > >> > >> ПК> Народ, объясните мне пожалуйста зачем в Линуксе может понадобиться > >> ПК> временное превышение полномочий, как тут кто-то недавно сказал??? Я > >> ПК> вообще ни ситуации такой представить не могу ни смысл самого понятия > не > >> ПК> могу понять. Кроме конечно того, что это такой себе мега-костыль. > >> > >> Пример. У меня есть сервер в Интернете, и машина в локальной сети, > >> которая его бэкапит. В автопилоте. Она, натурально, идет туда по ssh > >> юзером backup по ключу и запускает собственно команду бэкапа, сливающую > >> результат в этот ssh. По sudo без пароля. Ровно эту команду и никакую > >> другую. > >> > >> Предложи другой способ это сделать. Без необходимости открывать доступ > >> снаружи на бэкапящую машину и, следовательно, в локальную сеть. > >> Бэкапящая машина еще много для чего используется, и защищена она в > >> результате не в пример слабее того сервера. > > ПК> Просто: бэкап на сервере делает ПО от рута в место доступное backup с > ПК> соответствующими правами. ПО на машине в локальной сети просто этот > ПК> бэкап слизывает под пользователем backup без всяких повышений > ПК> привилегий. > > 1. Диск на сервере не резиновый. Места под бэкапы там нет. Слова > "сливающую результат в этот ssh" в моем письме были по делу, а не для > красного словца. > > 2. "Обратно-инкрементные" бэкапы (то, что дает rdiff-backup или > rsnapshot) по такой схеме делать невозможно.
Если загвоздка в том, что не хочется делать коннект Сервер->Бэкап, решение я написал другим письмом: VPN Бэкап->Сервер, rdiff-backup Сервер->Бэкап через VPN. > >> ПК> Я понимаю так, что если тебе иногда надо выполнять команды с другими > >> ПК> привилегиями - меняй привилегии с подтверждением их обладания (su), в > >> ПК> остальных случаях права правильно надо настраивать. Иначе > отслеживать у > >> ПК> кого какие привилегии РЕАЛЬНО могут быть очень тяжело, эвристический > >> ПК> анализ нужен: Вася может рутом выполнять некоторые команды, Петя > имеет > >> ПК> ssh доступ к Васе по ключам без пароля, пол офиса Васи иногда сидит > за > >> ПК> компом Васи..., и, РЕАЛЬНО рутом выполнять некоторые команды уже > может > >> ПК> пол страны. > >> > >> Похрен. Яйца отрывать будем Васе. Вместе с записями в sudoers. > >> Остальное - его проблемы. > > ПК> Понятно, что ответственность лежит на Васе, но в целом такая система > ПК> *неоправданно* сложнее. > > >> За моим компом пол-офиса может сидеть. Но не под моим логином. У них > >> на нем свои логины есть. > > ПК> Не все такие правильные как ты. > То есть когда по техническим причинам привилегия нужна, а по > смыслу - нет. Мне так и не подсказали случаев где решение возможно только в помощью sudo. Мне почему-то кажется, что таких нет. Давайте разберёмся когда "техническим причинам привилегия нужна"? > Если "работающая" - это не оправдание усложнения, то что может быть > оправданием? Оправдание. Только если есть несколько вариантов сделать систему "работающей", почему бы не выбрать тот, который: тянет меньше последствий, предрасполагает к дисциплине, потенциально менее опасен? При всём при этом sudo *может* быть более простым вариантом в первоначальной настройки, если не принимать во внимание последующее обслуживание. -- Покотиленко Костик <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
