Недостатки Umask 077?

Какие минусы, из-за ограничительного значения маски 077? Многие дистрибутивы (я полагаю, все, кроме Red Hat?) Имеют значение по умолчанию 022, настроенное в / etc / profile. Это кажется слишком небезопасным для не настольной системы, к которой обращаются несколько пользователей, и безопасность вызывает беспокойство.

В соответствующей заметке в Ubuntu домашние каталоги пользователей также создаются с разрешениями 755, и установщик утверждает, что это облегчает пользователям обмен файлами. Если предположить, что пользователям удобно устанавливать разрешения для совместного доступа к файлам вручную, это не проблема.

Какие еще минусы есть?

022 делает вещи удобными. 077 делает вещи менее удобными, но в зависимости от обстоятельств и профиля использования, это может быть не менее удобно, чем использование sudo.

Я бы сказал, что, как sudoи фактическая, измеримая выгода для безопасности, которую вы получаете от этого, ничтожна по сравнению с уровнем боли, который вы причиняете себе и своим пользователям. Как консультант, меня презирали за мои взгляды sudoи бросали вызов сломать многочисленные sudoнастройки, и мне еще нужно больше 15 секунд, чтобы сделать это. Ваш звонок.

Знать об umaskэтом хорошо, но это всего лишь одна кукурузная хлопья в «полном завтраке». Может быть, вам следует спросить себя: «Прежде чем я начну работать с конфигами по умолчанию, согласованность которых нужно будет поддерживать при разных установках, и которые нужно будет документировать и обосновывать для людей, которые не имеют дураков, что это может купить мне?"

Umask также является встроенным в bash, который настраивается отдельными пользователями в их файлах инициализации оболочки ( ~/.bash*), так что вы не можете легко применить umask. Это просто по умолчанию. Другими словами, это не сильно тебя покупает.

Самый очевидный недостаток - когда вы начинаете создавать файлы / каталоги в общем каталоге, ожидая, что другие пользователи получат к ним доступ.

Конечно, нужно только не забыть установить правильный umask, прежде чем делать то, что должно быть доступно всем пользователям.

Еще одна оговорка (на самом деле не является недостатком, как только вы об этом узнаете), когда вы начинаете делать такие вещи, как sudo, такие как установка локальных программ, рубиновых гемов, яиц python (очевидно, не пакетов управления ОС), создание файлов конфигурации и так далее.

У вас будут проблемы, поскольку umask наследуется сессией sudo, поэтому только root сможет получить доступ к файлам / каталогам, которые вы создаете. Можно настроить sudo на автоматическую настройку umask так, как вы хотите: этот вопрос рассматривается на сайте superuser.com .

Umask не подойдет, если вы пытаетесь контролировать то, что другие пользователи видят друг от друга. Однако, если у вас есть и вы работаете с многочисленными файлами, которые чувствительны к тому моменту, когда запрашивать разрешение на доступ к ним менее утомительно / рискованно, чем просто позволять людям видеть все, что они хотят, лучше было бы использовать umask 077.

У меня есть несколько конфиденциальных файлов на файловом сервере, которым я управляю. Я думаю, что установка ограничительного umask, а затем периодического сценария, может быть, работа cron для установки более определенных разрешений для элементов в определенных папках, была бы идеальным решением для меня. Когда я это настрою, я опубликую здесь и сообщу, как это работает.

@ [Ребята, бьющие sudo] Создайте новую тему, она может занять несколько собственных тем, и эта тема про umask.

Сторонние приложения, использующие свои собственные системы установки, могут иметь встроенные предположения о системном umask по умолчанию.

В качестве практического примера, после обновления базы данных Oracle 10 в системе с установленным значением umask 077 приложениям в той же системе не удалось получить доступ к базе данных ... потому что библиотеки необходимы для клиентов базы данных, а каталоги - библиотеки находились в, теперь были защищены, так что только oracleпользователь мог получить к ним доступ, что, очевидно, было не таким, как все должно было работать.

Оказывается, процесс обновления Oracle специально не позаботился о том, чтобы разрешения клиентских библиотек позволяли их использовать другим пользователям, а вместо этого полагался на предположение, что файлы, добавленные средством обновления, будут созданы с помощью umask 022 и, таким образом, будут пригодными для использования. по умолчанию. После нескольких продуманных chmod -R a+rXкоманд для соответствующих каталогов все снова стало хорошо.

Конечно, этого можно было бы избежать, рассматривая oracleучетную запись как специальную системную учетную запись со стандартным umask 022 и ограничивая umask 077 только учетными записями пользователей, которые могут входить в систему ... но я думаю, что это хороший пример того, как "укрепляется" общий уровень «решения могут иметь непредвиденные побочные эффекты.

.rpmи .debпакеты несут явную информацию о разрешениях для любых файлов, которые они содержат, поэтому они обычно не имеют риска ошибок этого типа.

У меня есть эта строка в моем ~/.zshrc

umask 0077

установка его глобально, вероятно, не очень хорошая идея, но установка его как значения по умолчанию в вашем файле rc, вероятно, не повредит или даже не установит его как значение по умолчанию в /etc/skel/.rcфайле. система в целом вызовет проблемы, хотя.

Это вызовет проблемы на сервере; например, когда несколько приложений работают как разные пользователи, пытающиеся получить доступ к файлам от разных пользователей. Например, чтение файлов конфигурации apache или чтение dnsmasq.conf. Просто запустите его для пользователей, которые могут извлечь из этого пользу, например, отдельные домашние каталоги, не заданные явно /etc/profile.