Змінити право власності на файл під час операції запису

За замовчуванням umask - 0022:

usera@cmp$ touch somefile; ls -l
total 0
-rw-r--r-- 1 usera usera 0 2009-09-22 22:30 somefile

Каталог /home/shared/призначений для спільних файлів і повинен належати rootі sharedгрупі. Файли , створені тут userп (будь-який користувач) автоматично належить sharedгрупі. Існує робота по роботі з клієнтами, яка займається зміною власника користувача та володіння групою (будь-яких переміщених файлів) один раз на день:

usera@cmp$ cat /etc/cron.daily/sharedscript

#!/bin/bash

chown -R root:shared /home/shared/
chmod -R 770 /home/shared/

Я писав дійсно великий файл у загальний каталог. Він мав мене ( usera) як власника користувача, а sharedгрупу як власника групи. Під час операції запису виконувалася робота cron, і я все ще не мав проблем із завершенням процесу запису.

Розумієш. Я думав, що це станеться:

1. Я пишу файл. Дані про дозвіл та дані про право власності на файл виглядають так:-rw-r--r-- usera shared
2. Робота з хроном починається! Рядок chown обробляється, і тепер файл належить rootкористувачеві та sharedгрупі.
3. Оскільки група, яка володіє, лише має доступ до читання до файлу, я отримую помилку в записі файлу! Бум! Кінець історії.

Чому операція вдалася? Посилання на якусь довідкову документацію для резервного копіювання причини було б дуже вітається (оскільки я міг би використовувати її для вивчення деталей).

Afaik, POSIX 1003.1 вимагає лише fopen, щоб повернути помилку [EACCES] за недостатньої кількості привілеїв. Наступні операції, такі як fputc, можуть повернути помилку дескриптора файлу [EBADF], але я не думаю, що це означає, щоб покрити зміни дозволу, коли файл відкритий.

Роки тому я працював у компанії, де були створені наші сервери AIX, щоб вони використовували цю властивість, щоб зробити журнали більш безпечними. Коли сервіс запустився, корінь торкнеться /var/log/service.log, потім подасть його на серверuser: servergroup, su - запустіть службу (вона відкриє файл у режимі додавання), а потім подавить файл назад до root. Отже, сервіс може додавати до свого власного журналу, але не видаляти або перезаписувати його, тому якщо зловмиснику вдалося скомпрометувати службу, він не міг підробляти попередні записи журналу.

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

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

Як сказав Йоріл, дозволи відкриті, коли файл відкритий; вони не перевіряються після цього.

Пам'ятайте, що ви можете створити файл для запису з 400 (або 444, або 000) дозволами на файл. Вам, звичайно, потрібен дозвіл на створення файлу в каталозі, але ви можете мати доступ до запису до файлу, який ніхто інший (крім root) не може змінити.

Також зауважте, що групу можна встановити за замовчуванням, встановивши біт SGID у каталозі утримування:

chmod g+s /home/shared

Усі файли, створені в каталозі, належатимуть групі, яка є власником /home/sharedдо зміни групи. У MacOS X система поводиться так, як якщо бит SGID був встановлений у кожному каталозі - коли файл копіюється в каталог, група встановлюється в групу, якій належить каталог.