Чому налаштування ігнорується в каталогах?

У системах Linux ви можете успішно chmod u+s $some_directory, але замість того, щоб примушувати право власності на нові підкаталоги та файли бути власником каталогу, що містить (і також встановлювати підкаталоги u+s), як ви могли очікувати, система просто ігнорує встановлений біт. Підкаталоги та файли продовжують успадковувати UID процесів їх створення, а підкаталоги не встановлені за замовчуванням.

Чому налаштування ігнорується в каталогах і як я можу змусити систему розпізнати його?

Нагадаємо, що біти setuid та setgid були винайдені з зовсім іншою метою: змусити виконуваний файл виконуватись з uid або gid його власника, а не з uid або gid користувача, який запускає файл. Будь-яке інше використання - лише додаткова функція.

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

Отже, чому б не реалізувати ту саму функцію для setuid та файлу uid? Ну, uid набагато основніший ніж gid. Якщо ви реалізуєте це, часто файл не належить користувачеві, який його створив! Імовірно, користувач може все-таки змінити файл (якщо припустити, що umask є чимось розумним), але вони не можуть змінити біти дозволу. Важко побачити корисність цього.

Я вважаю, що відповідь на це питання стосується проблем безпеки "передачі файлів", які призвели до того, що більшість сучасних Unix-подібних ОС не дозволяють "передавати файли". "Видача файлів" - це коли користувач, що не користується користувачем, змінює право власності на файл іншим, ніж цей користувач. Ця можливість надає багато можливостей для пустощів.

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

Щодо зміни поведінки, вам доведеться змінити бібліотеки та утиліти ОС.

Один дуже хороший випадок використання для його здійснення:

Скажімо, у вас є багатопрофільний сервер з 3 захищеними сайтами. У вас створено 3 групи, по одній для кожного з різних сайтів, що обслуговують сайти. Усі файли на всіх сайтах повинні належати користувачеві апачі, щоб апач міг читати та записувати їх (drupal / wordpress тощо).

Якщо setuid, але працював як встановлений біт для дозволів каталогів, виглядатиме приблизно так:

/var/www/sitea - apache:groupa  rwS rwS ---
/var/www/siteb - apache:groupb  rwS rwS ---
/var/www/sitec - apache:groupc  rwS rwS ---

Таким чином, кожна група обслуговуючого персоналу мала доступ до перегляду та торкання лише їх вмісту, але користувач веб-сервера apache міг обслуговувати весь контент, і користувачі не повинні турбуватися про зміну власності на завантажені файли.

Інший випадок використання для Anonymous ftp / http або навіть sftp / ssh. Група та GID у каталозі завантаження будуть кореневими, а також власник та UID. Інші дозволи будуть -wx. Це дозволить усім WRITE отримати доступ до каталогу завантажень, але вони не змогли прочитати нічого, як тільки він буде завантажений, і root матиме всі новостворені файли.

Отже, є два ідеально хороших та дійсних випадки використання для того, щоб функція UID в каталогах відповідала GID-біту.

Стівен Меркуріо

Трохи запізнюючись на вечірку, але у випадку, якщо майбутні читачі натрапляють на це;) Як зазначають інші, у стандартній файловій системі OS-X setUID для каталогів ігнорується - і, здається, це не простий спосіб ( mount -o.... чи що ні). Як це часто, сторінка man насправді не відповідає поведінці OS-X, про яку вона буквально говорить:

4000 (біт set-user-ID-on-Execution) [...] Каталоги з набором біта set-user-id змусять усі файли та підкаталоги, створені в них, належати власнику каталогу, а не uid процесу створення [...]

але він також перераховує можливість досягти такого ж ефекту, не відмовляючись від початкового права власності. Linux використовує '[g /] setfacls' для подібних ефектів (вони дозволу насправді не видно на перший погляд, тому вони можуть колись викликати неприємності).

Щодо "як я можу досягти подібних ефектів", прочитайте всю сторінку чоловіка та поспіль:

chmod +a 'guest allow read,write,delete,add_file,add_subdirectory,file_inherit,directory_inherit' ./[DIRECTORY]

ви можете перевірити через

ls -le

якщо все виглядає нормально. Подальші варіанти включають вставки правил на певних позиціях, видалення або заміну конкретних правил. Тут можна звернути увагу на два варіанти " file_inheritта directory_inherit", що дозволяють приєднати правила до нового каталогу / файлу.

Мені не дуже подобається використовувати setUID, але setGID дуже корисний на файлових серверах, де просто налаштування «основної» групи не працює або клієнти мають файлові маски, що забороняють записувати групу. Це вирішиться шляхом:

chmod +a 'mygroup allow read,write,delete,add_file,add_subdirectory,file_inherit,directory_inherit' /fileserver/groupfolders/mygroup

Ну, це повинно поважати стандарт. Я можу подумати на декількох сценаріях з sftp, лише щоб це врятувало мені багато клопотів, як з acl, так і з набором acl-mask, що робить sshd, і скиданням, що я повинен зробити для цієї маски.

Безпека за замовчуванням є цілком корисною, але якщо ви не робите це як варіант, ви просто створюєте крила.

https://www.gnu.org/software/coreutils/manual/html_node/Directory-Setuid-and-Setgid.html

Так чи інакше, це так, як зараз йде Linux, тому просто використовуйте acl, щоб обійти їх.

Відповідно до http://en.wikipedia.org/wiki/Setuid#setuid_and_setgid_on_directories біт встановлення ігнорується для каталогів як у системах UNIX, так і Linux. Однак можна змусити його діяти так, як ви очікували на FreeBSD.