Изменить владельца файла во время операции записи

Question

По умолчанию значение 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 n (любым пользователем), автоматически принадлежат shared группе. Существует cron-задача, которая заботится о смене владельца и группы владельцев (любых перемещенных файлов) один раз в день:

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. Работа cron начинается! Строка chown обрабатывается, и теперь файл принадлежит пользователю root и shared группе.
3. Поскольку группа-владелец имеет доступ только для чтения к файлу, я получаю ошибку записи в файл! Boom! Конец истории.

Почему операция прошла успешно? Ссылка на какую-либо справочную документацию для подтверждения причины была бы очень кстати (так как я мог бы использовать ее для изучения более подробной информации).

Answer 1

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

Несколько лет назад я работал в компании, где у нас были настроены наши серверы AIX, чтобы они использовали это свойство для повышения безопасности журнальных файлов. Когда служба запускалась, root нажимал /var/log/service.log, затем записывал ее в serveruser:servergroup, запускал службу (она открывала файл в режиме добавления), а затем отбрасывал файл обратно в root. Следовательно, служба может добавлять в свой собственный файл журнала, но не удалять и не перезаписывать его, поэтому, если злоумышленнику удастся скомпрометировать службу, он не сможет вмешаться в прошлые записи журнала.

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

Answer 2

Я думаю, причина в том, что когда включается cron, у вас все еще есть действительный дескриптор файла, так что вы можете использовать его как обычно ... Другими словами, система проверяет ваши права только при попытке открыть его, а не при каждой операции с файлом.

Answer 3

Как сказал Джорил, права доступа актуальны при открытии файла; они не проверяются после этого.

Помните, что вы можете создать файл для записи с 400 (или 444, или 000) разрешениями на файл. Конечно, вам нужно разрешение на создание файла в каталоге, но вы можете иметь право на запись в файл, который никто другой (кроме root) не может изменить.

Также обратите внимание, что группу можно установить по умолчанию, установив бит SGID в каталоге хранения:

chmod g+s /home/shared

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