Недоліки umask 077?

Які мінуси для обмежувального умаска 077? Багато дистрибутивів (я вважаю, що всі, крім Red Hat?) Мають umask за замовчуванням 022, налаштований у / etc / profile. Це здається занадто небезпечним для не-робочої системи, до якої звертаються кілька користувачів, і безпека викликає занепокоєння.

У відповідній примітці на Ubuntu також створюються домашні каталоги користувачів з дозволами 755, і інсталятор заявляє, що це полегшує користувачам обмін файлами. Якщо припустити, що користувачі зручно встановлюють дозволи вручну для спільного використання файлів, це не проблема.

Які ще є мінуси?

022 робить речі зручнішими. 077 робить речі менш зручними, але залежно від обставин та профілю використання він може бути не менш зручним, ніж використання sudo.

Я б заперечував, що, як-от sudo, фактична вимірна вигода від безпеки, яку ви отримуєте від цього, є незначною порівняно з рівнем болю, який ви завдаєте собі та своїм користувачам. Як консультант, я був презирливий за свої погляди на sudoі намагався зламати численні sudoустановки, і мені ще потрібно більше 15 секунд, щоб зробити це. Твій дзвінок.

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

Umask - це також вбудована версія bash, яка встановлюється окремими користувачами у файлах ініціалізації оболонок ( ~/.bash*), тому ви насправді не можете легко застосувати umask. Це просто за замовчуванням. Іншими словами, це не дуже купує вас.

Найбільш очевидний мінус - це коли ви починаєте створювати файли / каталоги в спільному каталозі, очікуючи, що інші користувачі отримають доступ до них.

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

Ще один застереження (насправді не зворотний бік, як тільки ви це усвідомлюєте) - це коли ви починаєте робити судо такі речі, як установка локальних програм, рубінові дорогоцінні камені, яйця пітона (явно не керуючи пакетами ОС), створення файлів конфігурації тощо.

Ви потрапите в неприємності, оскільки umask успадковується сесією sudo, тому лише root зможе отримати доступ до файлів / dirs, які ви створюєте. sudo може бути налаштований для автоматичного встановлення umask так, як ви хочете: це питання висвітлюється на superuser.com .

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

У мене є керовані файли на файловому сервері, яким я управляю. Я думаю, що встановлення обмежувальної 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 читання конфігураційних файлів або читання pi-hole dnsmasq.conf. Просто запустіть його на тих користувачах, які могли б отримати користь від них, як-от окремі домашні каталоги, не вказані явно /etc/profile.