NTFS та підводні камені, Для системного адміністратора
NTFS та підводні камені
Останнім часом зауважую таку тенденцію, що користувачі та системні адміністратори не зовсім розуміють механізм роботи NTFS та поняття як “Діючі дозволи”. Нерозуміння цього питання призводить до того, що при видачі прав на певний ресурс користувачеві реальні права самого користувача виявляються не зовсім такими, як цього очікував адміністратор.
Отже, я спробую роз'яснити деякі підводні камені при призначенні прав Full Control користувачам та прав на рівні файлів.
Достеменно відомо, що право доступу ресурс (файл/папка) визначається ACL самого ресурсу. Однак, це не зовсім правильно. Розберемо типовий випадок:
Проблема:
Є папка, скажімо,Folder1 і користувачевіJohnSmith призначаються на неї правоFull Control. При цьому користувачJohnSmith матиме праваFull Control як на цю папку, так і на всі вкладені папки та файли. Але якщо адміністратор захоче на вкладений файлFile дати правоRead/Execute. Т.к. права доступу до ресурсу визначаються самим ресурсом, можна припустити, що користувачJohnSmith матиме право Full Control на всю папкуFolder1 і всі її підпапки, крім файлаFile1. У цьому можна сміливо переконатися, якщо переглянути вкладку Effective Permissions у додаткових властивостях безпеки файлу. Однак, приходитьJohnSmith і спокійно видаляє файл. Резонне питання, чому так? Адже Effective Permissions показує, що у користувача має рацію Тільки читання!”. Ось тут необхідно вловити одну тонкість:
- право видалення файлу не від дозволів самого файла, а батьківської папки.
Справа в тому, що при видаленніфайла NTFS не бере до уваги дозволу самого файла, а дивиться право батьківської папки цього файла. А якщо подивитися властивості батьківської папки, то там буде відзначено дозвілDelete subfolders and files. При цьому не важливо, чи успадковує файл дозволу від батька папки, чи ні. Саме правоDelete subfolders and files перекриває право самого файлу (Read ) і дозволяє видалити цей файл.
Вирішення проблеми:
Дуже багато хто спотикається на ці граблі, тому для ефективного, а головне, гарантованого призначення прав користувачеві слід керуватися такими правилами:
- не задавати права на ресурси лише на рівні файлів, лише на рівні папок;
- не давати користувачам праваFull Control на папку, а лишеModify ;
- Створювати ієрархію дозволів у вигляді ялинки. Тобто. збільшуючи права користувача на ресурс, спускаючись по дереву. Іншими словами “найменші права на корінь ресурсу та розширювати права вже на дочірні ресурси.
У другому пункті відзначеноModify. ЧомуModify, якщо це по суті дорівнюєFull Control ? Справа в тому, що правоModify не містить праваDelete subfolders and files, а значить, що при праві читання на файл користувач вже не зможе його видалити.
Проблема:
Рішення:
вирішення цієї ситуації (точніше її запобігання) ґрунтуватиметься на наступних правилах: