Оборотные стороны umask 077?
Предположим, что Вы обмениваетесь данными с компьютером на порте <1024, и Вы знаете, что компьютер выполняет некоторый вариант Unix. Затем Вы знаете, что сервис, работающий на том порте, утвержден системным администратором: это работает как корень или по крайней мере должно было быть запущено как корень.
На широком, диком мире Интернета это не имеет значения. Большинство серверов администрируемо теми же людьми как сервисы, работающие на них; Вы не доверяли бы корням больше, чем другие пользователи.
С многопользовательскими машинами, особенно в локальной сети, это может иметь значение. Например, в дни перед гражданской криптографией, популярный метод рабочих команд оболочки на другой машине был rsh (удаленная оболочка); Вы могли использовать аутентификацию по паролю, или Вы могли пройти проверку подлинности только путем доказательства, что Вы были пользователем X на машине (с машиной B знающий, что X@A мог войти в систему как X@B без пароля). Как доказать это? rsh клиент является корнем setuid и использует номер порта <1024, таким образом, сервер знает, что клиент, с которым он говорит, защищен и не будет лгать, относительно которого пользователь на A вызывает его. Так же NFS был разработан, чтобы быть прозрачным относительно пользователей и полномочий, таким образом, общая конфигурация была то, что в локальной сети каждая машина использовала ту же пользовательскую базу данных и пользователя N в, монтирующиеся файловые системы с сервера B получат полномочия пользователя N в B. Снова, то, что клиент NFS происходит из номера порта <1024, доказывает, что корень в A исследовал клиент NFS, который, как предполагается, удостоверяется что, если он передает запрос, подразумевающий быть от пользователя N затем, что запрос действительно от пользователя N.
Неавторизованные пользователи, не бывшие способные выполнять серверы на низких портах, являются другим преимуществом, но не основным. Назад в дни, спуфинг был вполне новинкой, и пользователи, выполняющие серверы имитации, будут быстро аннулированы бдительными администраторами так или иначе.
022 делает вещи удобными. 077 делает вещи менее удобными, но в зависимости от обстоятельств и профиля использования, это не могло бы быть немного менее удобно, чем необходимость использовать sudo.
Я обсудил бы это, как sudo, фактическая, измеримая безопасность приносит пользу Вам, усиление от этого незначительно по сравнению с уровнем боли, которую Вы причиняете себе и Вашим пользователям. Как консультант, я презирался для моих представлений о sudo и оспариваемый повредиться многочисленный sudo установки, и я должен все же занять больше чем 15 секунд, чтобы сделать так. Ваш вызов.
Знание о umask хорошо, но это - просто единственные Кукурузные хлопья в "полном завтраке". Возможно, необходимо ли спрашивать себя, "Прежде чем я пойду, унавоживая с конфигурациями по умолчанию, непротиворечивость которых должна будет сохраняться через установки, и который должен будет быть зарегистрирован и выровнен по ширине людям, которые не являются недалекими, что это собирающееся покупать меня?"
Umask является также ударом, встроенным, который устанавливаем отдельными пользователями в их файлах инициализации оболочки (~/.bash*), таким образом, Вы действительно не можете легко осуществить umask. Это - просто значение по умолчанию. Другими словами, это не покупает Вас очень.
Самая очевидная оборотная сторона - когда Вы начинаете создавать файлы/каталоги в общем каталоге, ожидая, что другие пользователи получат доступ к ним.
Конечно, это - только вопрос не упущения установить корректный umask прежде, чем сделать материал, который должен быть совместно использован всеми пользователями.
Другой протест (не действительно оборотная сторона, после того как Вы знаете о нем) состоит в том, когда Вы начинаете делать материал sudo, такой как установка локальных программ, рубиновых драгоценных камней, яйца Python (не, ОС управляет пакетами, очевидно), создавая конфигурационные файлы, и так далее.
Вы попадете в беду для umask, наследован sudo сессией, поэтому только базируйтесь, сможет получить доступ к файлам/директорам, которые Вы создаете. sudo может быть настроен для автоматической установки umask путем, Вы хотите: этот вопрос покрыт на superuser.com.
-
1и последняя причина являются серьезным основанием к
su -и удостоверьтесь, что корень имеет другой umask..., но о... человечность не верит в корень... – xenoterracide 19.08.2010, 12:41 -
2@xenoterracide:
sudo su -хорошо работает. Ubuntu, как MacOSX, не верит в корень, в который можно просто войти. Лично, мне нравится иметь необходимость сказать, что что-то как "Simon Говорит" для корневых команд большую часть времени. – David Thornley 19.08.2010, 14:21 -
3@xenoterracide а? какова Ваша точка? и sudo и su позволяют, чтобы корень имел другой umask. @David можно использовать sudo-i вместо sudo su – zarkdav 19.08.2010, 21:34
-
4@xenoterracide: На самом деле использование корневой команды означает, что я, вероятно, введу что-то в неправильное окно. Используя средства "sudo" я должен указать, что хочу, чтобы это было выполнено корнем. Я знаю отлично существует корневая учетная запись, таким образом, я не вижу, куда ложное чувство защищенности прибывает из. Просто еще один небольшой ритуал (как то, чтобы сидеть сложа руки), который делает его менее вероятно, я сделаю что-то фатально глупое как корень. – David Thornley 20.08.2010, 01:03
-
5sudo и su, инструменты, как любая команда. Никакая потребность смешать чувства с утилитой. sudo приносит гибкую конфигурацию, аудит и удобство использования к su. Конечно, нужно знать о различных возможностях и на самом деле нуждается в них для распознавания преимуществ. Я думаю это "ложное чувство защищенности", Вы говорите о, должен быть более соответственно предназначен для Ubuntu "корневая учетная запись, отключенная" политика. Вот в чем разница между инструментом и политикой. Можно привести хорошие аргументы против политики. Отклонение полноценности инструмента, потому что каждый не соглашается с политикой, просто неправильный. – zarkdav 28.08.2010, 13:48
Umask не был бы соответствующим, при попытке управлять тем, что другие пользователи видят друг от друга. Однако, если Вы имеете и работаете с многочисленными файлами, которые чувствительны до такой степени, что попроситься разрешения получить доступ к ним является менее надоедливым/опасным, чем просто разрешение людям видеть то, что они хотят, чем umask 077 был бы хорошей идеей.
У меня есть некоторые чувствительные файлы на файловом сервере, которым я управляю. Я думаю, устанавливая строгий umask, затем имеющий периодический сценарий, возможно, задание крона для установки более определенных полномочий на объекты в определенных папках было бы идеальным решением для меня. Когда я настроил это, я отправлю назад здесь и сообщу, как это работало.
[Парни, колотящие sudo], Начинают новую дискуссию для него, могло потребоваться несколько потоков самих по себе, и этот поток о umask.
У меня есть эта строка в моем ~/.zshrc
umask 0077
установка его глобально, вероятно, не, хорошая идея, но устанавливание по умолчанию его в Вашем емкостно-резистивном файле, вероятно, не собирается причинять боль или даже устанавливает его по умолчанию в /etc/skel/.rc файл. в масштабе всей системы вызовет проблемы все же.
Это вызовет проблемы на сервере; например, когда несколько приложений работают от имени разных пользователей, пытающихся получить доступ к файлам от разных пользователей. Например, apache читает конфигурационные файлы или pi-hole читает dnsmasq.conf. Просто запустите его для пользователей, которые могут извлечь из этого пользу, например, для отдельных домашних каталогов, явно не заданных в /etc/profile.
Сторонние -сторонние приложения, использующие собственные системы установки, могли -иметь встроенные предположения о umask системы по умолчанию.
В качестве практического примера: после обновления базы данных Oracle 10 в системе с umask, установленным на 077, приложениям в той же системе не удалось получить доступ к базе данных... потому что библиотеки, необходимые для клиентов базы данных, и каталоги, в которых находились библиотеки, теперь были защищены, так что только пользователь oracleмог получить к ним доступ, что, очевидно, не должно было работать так, как предполагалось.
Оказывается, процесс обновления Oracle специально не заботился о том, чтобы разрешения клиентских библиотек позволяли другим пользователям использовать их, а вместо этого полагался на предположение, что файлы, добавляемые средством обновления, будут созданы с umask 022 и поэтому можно использовать по умолчанию. После нескольких разумных chmod -R a+rXкоманд для соответствующих каталогов все снова стало хорошо.
Конечно, этого можно было бы избежать, рассматривая учетную запись oracleкак специальную системную учетную запись со стандартным umask 022 и ограничивая umask 077 фактическим входом только в учетные записи пользователей, способных -... но я думаю, что это хороший пример того, как общие «укрепляющие» решения могут иметь непредвиденные побочные эффекты.
.rpmи .debнесут явную информацию о правах доступа для любых содержащихся в них файлов, поэтому они, как правило, не подвержены риску возникновения ошибок такого типа.