пояснення щодо chown (1) специфікації POSIX

POSIX специфікації для chownкорисності згадує в своєму обгрунтування розділу про chown user:groupсинтаксис (раніше chown user.group) (курсив мій):

Метод 4.3 BSD для визначення власника та групи був включений у цей том POSIX.1-2008, оскільки:

• Бувають випадки, коли бажану кінцеву умову не вдалося досягти за допомогою утиліт chgrp та chown (які змінили лише ідентифікатор користувача). (Якщо поточний власник не є членом потрібної групи, а бажаний власник не є членом поточної групи, функція chown () може не працювати, якщо одночасно не змінитись і власник, і група.)

Я думав, що user:groupсинтаксис - це зручність. Тепер з вищевикладеного випливає, що ви можете зробити те, з чим chown user:groupне можетеchgrp group; chown user

Тепер цей текст для мене не має сенсу. У 4.3BSD тільки root може змінити власника файлу, тому в будь-якому випадку немає обмежень у тому, що він може робити.

SysV та декілька інших систем дозволяють (або використовуються для дозволу) власнику файлу змінювати користувача та групу файлів на що-небудь, але навіть у цій системі цей текст для мене не має сенсу. Гаразд, якщо хтось робить chown someone-else the-file, не можна робити chgrp something-else the-fileцього, тому що він більше не є власником файлу, але нічого не заважає йому робити це chgrpпершим (залишаючись власником файлу) і chownпісля, і це не те, що текст вище точно сказаний.

Я не розумію, що власний і бажаний власник не є членом поточної групи .

Отже, які умови можуть виконувати функцію chown (), якщо одночасно не змінити власника та групу та в якій системі?

Підсистема Microsoft Interix Unix (нині в відставку) для його ядра NT наносила трохи по- іншому з правами доступу користувачів і груп , ніж деякі інші роблять:

Інформація про користувачів та групи зберігається в базі даних Access Access . І користувачі, і групи зберігаються в одній базі даних, але імена груп і користувачів повинні бути унікальними; жодна група не може мати ім'я користувача та навпаки. (Ця база даних замінює файли /etc/passwdта /etc/groupsфайли в UNIX.) Користувачі та групи створюються за допомогою відповідної методології Windows (Менеджер користувачів, Користувачі та комп'ютери Active Directory або Місцеві користувачі та групи) або за допомогою net userкоманди Win32 . (Приклади скриптів оболонки для створення та видалення користувачів включаються до каталогу /usr/examples/admin.) Користувачі можуть належати до багатьох груп.

Ось деякі більш конкретні ручної витримки:

У Windows або користувач, або група можуть володіти об'єктом. Це відрізняється від UNIX, в якому об'єктом володіє лише користувач.

Windows ідентифікує всіх користувачів та груп внутрішньо, використовуючи ідентифікатор безпеки (SID) . Алгоритм хешування генерує унікальні значення SID; жоден користувач або група не матимуть однакового SID.

Користувачі та групи, які мають дозвіл на доступ до об’єкта, ідентифікуються за допомогою їх SID. Усі об'єкти, які можна захистити за допомогою Windows, мають дискреційний список контролю доступу (DACL), який складається з окремих записів, що називаються записами контролю доступу (ACE). ACE включає дві важливі частини інформації: SID користувача або групи та опис того, який доступ до об'єкта має окремий користувач або група.

CHGRP

... Змініть ідентифікатор групи для файлу ... користувач, який викликає chgrp (1), повинен належати вказаній групі та бути власником файлу або мати відповідні привілеї.

ЗНАЧЕНИЙ

... Операнди власника та групи є необов’язковими; однак треба вказати. Якщо вказаний операнд групи, йому повинен передувати двокрапка (:).

Власника можна вказати або числовим ідентифікатором користувача, або іменем користувача. Якщо ім'я користувача також є числовим ідентифікатором користувача, операнд використовується як ім'я користувача. Група може бути числовим ідентифікатором групи або назвою групи. Якщо ім'я групи також є числовим ідентифікатором групи, операнд використовується як ім'я групи.

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

Як я читав, це означає, що якщо ваш обліковий запис користувача належить до групи Windows з достатніми привілеями, щоб змінити дозволи файлу, які належать цій групі, то цей chgrpфайл можна ефективно використовувати поза контролем вашого облікового запису користувача. Це означає менший контроль, ніж у вас, chownі явні user:groupпараметри. У цьому контексті без можливості декларування, user: і :group ви ніколи не могли б досягти таких самих результатів, як інакше.

Ось посилання на докладний погляд на те, як Interix взаємодіє з Windows ACL з акцентом на те, як такі знання можуть застосовуватися до файлових систем Samba в інших варіантах Unix.

Ось посилання на застарілий документ Solaris, що описує налаштування, rstchownяке ...

Вказує, чи діє семантика POSIX для chown(2)системного виклику ...

Мабуть, якщо для параметра встановлено значення 0...

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

Така опція не скасовує відповідність Solaris POSIX . Просто те, що це варіант, взагалі кваліфікує його як відповідне :

Хоча всі реалізації, які відповідають POSIX.1-2008, підтримують усі описані нижче функції, можуть існувати процедури конфігурації, що залежать від системи або залежать від файлової системи, які можуть видалити або змінити будь-яку або всі ці функції. Такі конфігурації не слід робити, якщо потрібно чітке дотримання.

Наступні символічні константи визначаються зі значенням, відмінним від -1. Якщо константа визначена з нульовим значенням, додатки повинні використовувати sysconf(), pathconf()або fpathconf()функцію, або getconfутиліту, щоб визначити , які функції присутні в системі , в той час , або для конкретного імені шляху в питанні.

_POSIX_CHOWN_RESTRICTED

Використання chown()обмежується процесом з відповідними привілеями та зміною групового ідентифікатора файлу лише до ефективного ідентифікатора групи процесу або до одного з його додаткових ідентифікаторів групи.

chown()Функція системи - яка є документованої системою виклику проводиться як в chownі chgrpоболонці утиліта - це вказана на провал з багатьох причин. Серед них:

EACCES Дозвіл на пошук заборонено на компоненті префікса шляху.

ELOOP Цикл існує в символічних посиланнях, що виникають під час вирішення аргументу шляху.

EPERM Ефективний ідентифікатор користувача не відповідає власнику файлу, або процес виклику не має відповідних привілеїв, а _POSIX_CHOWN_RESTRICTED вказує на необхідність такого привілею.

Однак поведінка щодо надання прав на модифікацію дозволів для некористуючих користувачів ніколи не була характерною для Solaris. У цій публікації на форумі дуже чудово висвітлюється дозвіл файлів Unix, якщо автор заявляє:

Спочатку Unix дозволяв власнику файлів дарувати файл. Власник файлу може змінити власника на когось іншого. Некористувальницький користувач не міг скасувати цю операцію ... BSD [пізніше] видалено chownз некореневих користувачів ... [частково тому, що ... ... він реалізував дискові квоти, які могли б обмежити кількість дискового простору Користувач міг би мати файлову систему ... Неслухняні користувачі могли подарувати великі файли, щоб проскочити квоти.

Сьогодні непросто сказати, чи може некореневий chownфайл. Багато версій Unix дозволяють обидва способи поведінки ...

Ще одна хороша - і нещодавніша - публікація у списку розсилки цитує це та продовжує:

За замовчуванням для більшості ОС призначено chownобмеження лише до root. І існує консенсус про те, що слід залишатися таким з міркувань безпеки. Якщо користувач, що не має root, змінює власника файлу і будь-який біт виконання включений, SUIDі SGIDбіти повинні бути очищені. З цим може статися або не статися root.

Я думаю, що останній абзац говорить це добре.

У цій статті також посилається CAP_CHOWNна керування цим об'єктом в Linux (це повинно впливати лише на POSIX_CHOWN_RESTRICTEDповедінку) . Існує також CAP_FOWNERможливість, це трохи по-іншому в поведінці.

І як ви зазначаєте у 2003 році :

Зауважте, що принаймні в HPUX ви можете змінити власника своїх файлів ( rootнаприклад, навіть якщо ви не є приватним користувачем ...

... що залежало від setprivgroupпараметра конфігурації .

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

В цьому випадку , chown то chgrp зазнає невдачі , як користувач більше не матиме права змінювати дозволу цього файлу, а chown user:group- до тих пір , як група є одним користувачем власного - успіху.

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

Існує також велика документація щодо різних можливих ефектів дозволів на файли, обходу дерев та символічних посилань, які можуть спричинити подібний збій щодо -Rекурсивних chownпрограм тут:

З заголовків розділу POSIX XRAT Третій та Четвертий домени :

Як правило, користувачі, що визначають можливість переходу ієрархії файлів, бажають оперувати єдиною фізичною ієрархією, і тому символічні посилання, які можуть посилатися на файли за межами ієрархії, ігноруються. Наприклад, файл власника chown - це інша операція від тієї ж команди з вказаною опцією -R. У цьому прикладі chown owner fileтут описана поведінка команди , тоді як поведінка chown -Rфайлу власника команди описана в третьому та четвертому доменах.

... Існує проблема безпеки з дефолтом до логічної прогулянки. Історично склалося, що команда chown -Rкористувальницький файл був безпечним для суперкористувача , оскільки Setuid і setgid біти були втрачені , коли була змінена форма власності файлу. Якби прогулянка була логічною, зміна права власності більше не була б безпечною, оскільки користувач міг би вставити символічне посилання, що вказує на будь-який файл у дереві. Знову ж таки, це потребує додавання до команд, які здійснюють ієрархічний обхід, а не опосередковано через символічні посилання, а історичні сценарії, що здійснюють рекурсивні прогулянки, миттєво стануть проблемами безпеки. Хоча це здебільшого проблема системних адміністраторів, бажано не мати різних за замовчуванням для різних класів користувачів.

...

У 4.3 BSD chgrpпід час обходу дерева змінив групу символічної ланки, а не цілі. Символічні посилання в 4.4 BSD не мали власника, групи, режиму чи інших стандартних атрибутів системного файлу UNIX.

І на chgrpвласній сторінці POSIX з'являється це, що вказує на можливу неповну -Rекурсивну дію або, принаймні, на те, що раніше було:

Версії System V і BSD використовують різні коди статусу виходу. Деякі реалізації використовували статус виходу як підрахунок кількості помилок, що виникли; ця практика непрацездатна, оскільки може переповнити діапазон дійсних значень статусу виходу. Стандартні розробники вирішили замаскувати їх, вказавши лише 0 та> 0 як значення виходу.

Припущення 1: правила визначення того, чи chownвдалося перевірити цільового користувача та частини групи незалежно, тобто вони мають форму user_condition(target_uid, other_environment_parameters) && group_condition(target_gid, other_environment_parameters).

Припущення 2: chown(file, -1, -1)успішно.

Припущення 3: правила визначення chownуспіху не залежать від того, до якої групи належить файл.

Висновок: якщо chown(file, uid, gid)вдасться досягти успіху, то так би chown(file, -1, gid) && chown(file, uid, -1).

Я не знаю варіанту Unix, який би порушив будь-яке з цих припущень, вони здаються досить безпечними.

Це речення має вигляд чогось, що хтось з комітету сказав, коли вони втомилися після годинних дискусій, скільки варіантів може поміститися на голову psдзвінка - або що секретар відписав - і що ніхто не зловив під час огляду. Зрештою, є й інші, вагомі причини, щоб дозволити користувачеві та групі змінюватись автоматично, включаючи причину продуктивності, також вказану в обґрунтуванні POSIX, а також атомічність (ах, якщо б лише один виклик змінити право власності та дозволи ).

Випадок, коли припущення 3 може бути помилковим, - це система, де процес може отримати можливість змінити власників файлів, але тільки якщо вони мають дозвіл на запис у файл. Хоча дещо реалістично, я не знаю жодної системи, де це так. Потім chgrpгрупа з процесу, який не працює ні як root, ні як власник файлу, не може зробити файл забороненим на пізніше chown.

Для рекурсивного дзвінка існують крайні випадки, коли цілий пропуск, за chgrpяким слідує цілий пропуск, chownможе вийти з ладу, коли один прохід вдався б. Це не дуже переконливий аргумент, оскільки він містить каталоги про те, що власник не має дозволу на переміщення, і програма, яка хотіла захистити від усіх подібних випадків, у будь-якому разі повинна попрямувати з дозволами. Тим не менш, це технічно відповідає умові цієї обґрунтування. Припустимо, що запущений процес має ефективну користувачу alice, ефективну групу staffта можливість змінювати власників файлів довільно (не просто видавати їх; декілька варіантів Unix мають таку можливість, хоча це рідко надається некореневим процесам).

$ ls -ld dir dir/file
d---rwx---  2 charlie  staff        1024 Apr  1  1970 dir
drw-rw----  2 charlie  staff          42 Apr  1  1970 file
$ chgrp -R students dir
$ chown -R bob dir
chown: dir: permission denied