Захист файлу і права доступу
Оскільки файли - це захищені об'єкти (securable objects). звернення до них, регулюється моделлю управління доступом, яка керує доступом до всіх інших захищених об'єктах у Windows. Докладне пояснення цієї моделі см. В розділі Управління доступом.
Ви можете встановити дескриптор безпеки (security descriptor) для файлу або каталогу, коли викликаєте функцію CreateFile. CreateDirectory або CreateDirectoryEx. Якщо Ви для параметра lpSecurityAttributes визначаєте значення ПУСТО (NULL). файл або каталог отримує заданий за замовчуванням дескриптор безпеки. Списки контролю доступу (ACL) в заданому за замовчуванням дескрипторі безпеки для файлу або каталогу успадковуються від його каталогу попереднього рівня.
Зверніть увагу! на те, що заданий за замовчуванням дескриптор безпеки призначається тільки тоді, коли файл або каталог недавно створені, а не тоді, коли елемент перейменований або переміщений.
Щоб витягти дескриптор безпеки об'єкта файлу або каталогу, викличте функцію GetNamedSecurityInfo або GetSecurityInfo. Щоб змінити дескриптор безпеки об'єкта файлу або каталогу, викличте функцію SetNamedSecurityInfo або SetSecurityInfo.
Правильні права доступу для файлів і каталогів включають в себе стандартні права доступу (standard access rights) DELETE (видалення), READ_CONTROL (управління читанням), WRITE_DAC (виборчий контроль за доступом до запису) і WRITE_OWNER (монопольна запис). Нижченаведена таблиця перераховує права доступу, які є специфічними для певних файлів і каталогів.
FILE_APPEND_DATA
FILE_WRITE_ATTRIBUTES
FILE_WRITE_DATA
FILE_WRITE_EA
STANDARD_RIGHTS_WRITE
SYNCHRONIZE
Windows Me / 98/95: Нижче перераховані єдині підтримувані права доступу: DELETE. FILE_WRITE_ATTRIBUTES. GENERIC_READ і GENERIC_WRITE.
Windows порівнює витребувані права доступу і інформацію в маркері доступу потоку з інформацією в дескрипторі безпеки об'єкту каталогу або файлі. Якщо порівняння не забороняє всі витребувані права доступу, які повинні бути наданими, дескриптор об'єкта повертається потоку, і права доступу надаються. За детальною інформацією про цей процес зверніться до статті Взаємодія між потоками і захищеними об'єктами.
За замовчуванням, дозвіл на доступ до файлу або каталогу управляється суворо списками контролю доступу (ACL) в дескрипторі безпеки, пов'язаних з цим файлом або каталогом. Зокрема, дескриптор безпеки батьківського каталогу не використовується, щоб управляти доступом до будь-якого дочірньому файлу або каталогу. Право доступу FILE_TRAVERSE може бути реалізовано, шляхом видалення привілеї BYPASS_TRAVERSE_CHECKING у користувачів. Це не рекомендується в загальному випадку, так як багато програм неправильно обробляють помилки обходу каталогу. Головне використання права доступу FILE_TRAVERSE в каталогах - це включити відповідність деякому стандарту POSIXIEEE і ISO. коли потрібна здатність до взаємодії з системами Unix.
Модель системи безпеки Windows передбачає для дочірнього каталогу спосіб успадкування або запобігання успадкування, одного або декількох елементів списку контролю доступу (ACE) в дескрипторі безпеки батьківської директорії. Кожен елемент списку контролю доступу (ACE) містить інформацію, яка обумовлює, як ці елементи можуть бути успадковані, і чи будуть вони впливати на успадковує об'єкт каталогу. Наприклад, деякі успадковані ACE керують доступом до успадкованого об'єкта каталогу і вони називаються робочими елементами списку контролю доступу (ACE) (effective ACEs). Всі інші елементи списку контролю доступу (ACE) називаються тільки успадкованими ACE (inherit-only ACEs).
Модель системи безпеки Windows також здійснює і автоматичну спадковість елементів списку контролю доступу (ACE) дочірніми об'єктами згідно з правилами успадкування ACE (ACE inheritance rules). Ця автоматична спадковість, поряд з успадкованою інформацією в кожному ACE. встановлює якісь обмеження захисту передаються вниз в ієрархії каталогів.
Зверніть увагу! на те, що Ви не можете використовувати відмову в доступі ACE. щоб не допустити звернення до файлу тільки для GENERIC_READ. або тільки для GENERIC_WRITE. Для таких об'єктів файлів це відбувається тому, що універсальні схеми набору прав і для GENERIC_READ. і для GENERIC_WRITE включають в себе право доступу SYNCHRONIZE. Якщо елемент списку контролю доступу (ACE) відмовляє, то GENERIC_WRITE звертається опікуну, а опікун запитує доступ GENERIC_READ. так що запит завершиться помилкою, тому що потенційно він включає в себе доступ SYNCHRONIZE. в якому побічно була відмова ACE. і навпаки. Замість того, щоб використовувати відмову в доступі ACE. використовуйте дозвіл доступу ACE. щоб явно дати можливість використовувати дозволені права доступу.
Привілеї доступу SE_BACKUP_NAME і SE_RESTORE_NAME були спеціально створені, щоб забезпечити цю здатність резервного копіювання програми. Якщо ці права доступу надаються і включаються в маркері доступу резервного прикладного процесу, тоді він може викликати функцію CreateFile. щоб відкрити ваш файл або каталог для резервного копіювання, встановлюючи стандартне право доступу READ_CONTROL як значення параметра dwDesiredAccess в ній. Однак, щоб ідентифікувати викликає процес як процес резервування, виклик CreateFile повинен включати в себе прапорець FILE_FLAG_BACKUP_SEMANTICS в параметрі dwFlagsAndAttributes. Повний синтаксис виклику функції - нижче: