В Срд, 10/12/2008 в 18:33 +0300, Artem Chuprina пишет: > Покотиленко Костик -> [email protected] @ Wed, 10 Dec 2008 > 12:56:25 +0200: > > ПК> Если загвоздка в том, что не хочется делать коннект Сервер->Бэкап, > ПК> решение я написал другим письмом: VPN Бэкап->Сервер, rdiff-backup > ПК> Сервер->Бэкап через VPN. > > Я там ответил конкретно, а тут отвечу абстрактно. Ты предложил коннект > Сервер->Бэкап. От того, что он делается через VPN, он не перестает быть > коннектом Сервер->Бэкап.
Я предложил этот вариант, так как мне показалось ты не хочешь/можешь пробросить порт со шлюза локалки на комп в локалке, иначе же, конечно, rdiff-backup по ssh с сервера на комп в локалке от рута на обычного пользователя проще. И без всяких sudo и vpn. Скажи прямо, почему угробить сервер (вариант со взломом) - хрен с ним, а получить пользователя на компе, который бэкапы хранит - недопустимо? Я почему-то считаю, что в рамках нормальной рабочей жизни сервера, производить соединения сервер->куда-нибудь безопаснее, чем от-куда-нибудь->сервер, хотя и ловлю себя на мысли, что не могу объяснить почему. > >> То есть когда по техническим причинам привилегия нужна, а по > >> смыслу - нет. > > ПК> Мне так и не подсказали случаев где решение возможно только в > ПК> помощью sudo. Мне почему-то кажется, что таких нет. Давайте > ПК> разберёмся когда "техническим причинам привилегия нужна"? > > Всегда возможно сделать решение, которое обойдется без sudo. Не > вопрос. Вопрос в том, какова будет цена этого решения, по сравнению с > ценой решения на sudo, в интересующих нас параметрах, в первую очередь > сложность и безопасность. Вон вышеприведенное тобой решение с VPN - оно > и сложнее, и опаснее. Хотя возможно, не вопрос... Если интересно, давай продолжим сравнивать, мне интересно. > >> Если "работающая" - это не оправдание усложнения, то что может быть > оправданием? > > ПК> Оправдание. Только если есть несколько вариантов сделать систему > ПК> "работающей", почему бы не выбрать тот, который: тянет меньше > ПК> последствий, предрасполагает к дисциплине, потенциально менее опасен? > > Ну, для начала ты все же говорил о неоправданном _усложнении_. Впрочем, > sudo еще и больше предрасполагает к дисциплине, и менее опасен. Если > таки проанализировать всю модель угроз, а не те полтора следствия, > которые кто-то случайно заметил. Давай анализировать. > ПК> При всём при этом sudo *может* быть более простым вариантом в > ПК> первоначальной настройки, если не принимать во внимание последующее > ПК> обслуживание. > > И в обслуживании тоже. Чтобы отобрать у человека права на конкретной > машине, мне достаточно вычистить его из sudoers. Если у него там su, > т.е. знание рутового пароля - мне надо поменять пароль и быстро сообщить > его всем, кому его положено знать. Если это более простой вариант, то > что такое более сложный? Вопрос про su не стоит, su - это рут, на нём и ответственность. Sudo - это недо-рут, и ответственность на нём [какая на нём ответственность?]. По определению, если ты даёшь кому-то рута, ты ему доверяешь систему. Если ты даёшь команду под sudo - не думаю, что ты ему доверяешь, иначе дал бы рута. Давая команду под sudo, какую ответственность ты налагаешь? Боюсь, что никакую, ибо облом держать таблицу ответственностей с галочками напротив каждой исполняемой команды. > Если мне надо дать возможность (плюс-минус любому) юзеру передернуть, > допустим, принт-сервер, я пишу скрипт и пишу в sudoers > > %users (ALL) = NOPASSWD: /that/script > > Покажи мне более простое и не более опасное решение. По моему проще разобраться, и сделать так чтобы не надо было передёргивать. Решение, конечно, с виду не простое, но... если каждому давать... запутаешься когда-нибудь... Не ты, так твой коллега, когда ты в отпуске будешь. В итоге, может и проще оказаться. > Впрочем, нафига я это тебе объясняю?.. Пошли эмоции, не хочешь не объясняй. -- Покотиленко Костик <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
