Измените принадлежность файла во время операции записи
По умолчанию 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 группа. Файлы, созданные здесь usern (любой пользователь) автоматически принадлежат shared группа. Существует задание крона, заботящееся об изменении пользователя владения и владении группой (любых перемещенных файлов) однажды в день:
usera@cmp$ cat /etc/cron.daily/sharedscript
#!/bin/bash
chown -R root:shared /home/shared/
chmod -R 770 /home/shared/
Я действительно писал крупно файл к общему каталогу. Это имело меня (usera) как владеющий пользователь и shared группа как владелец группы. Во время операции записи было выполнено задание крона, и у меня все еще не было проблемы при завершении процесса записи.
Вы видите. Я думал, что это произойдет:
- Я пишу файл. Полномочия файла и данные владения для файла похожи на это:
-rw-r--r-- usera shared - Задание крона умирает! Показанная строка обрабатывается, и теперь файл принадлежит
rootпользователь иsharedгруппа. - Поскольку у группы владения только есть доступ для чтения к файлу, я получаю ошибку при записи файла! Быстро растите! Конец истории.
Почему операция успешно выполнялась? Ссылка на некоторую справочную документацию для резервного копирования причины очень приветствовалась бы (поскольку я мог использовать ее для изучения большего количества деталей).
3 ответа
Afaik, POSIX 1003.1 требует только fopen возвращать ошибку [EACCES] на недостаточных полномочиях. Последующие операции как fputc могли бы возвратить [EBADF] плохую ошибку дескриптора файла, но я не думаю, что это предназначено для покрытия изменений разрешения, в то время как файл открыт.
Несколько лет назад, я работал в компании, где нам настраивали наши серверы AIX так, чтобы они использовали то свойство для создания файлов журнала более безопасными. Когда сервис запустился, корень коснулся бы /var/log/service.log, затем показанный его serveruser:servergroup, su - запускают сервис (он открылся бы, файл в добавляют режим), и затем показанный файл назад для укоренения. Следовательно, сервис мог добавить к его собственному файлу журнала, но не удалить или перезаписать его, поэтому если бы взломщику удалось поставить под угрозу сервис, то он не мог бы вмешаться в прошлые записи в журнале.
Подобный прием может использоваться для временных файлов: откройте файл, затем удалите его. Записи каталога не стало, и файл невидим, но так как дескриптор файла все еще открыт, inode все еще там. После того как Вы закрываете файл, число каналов переходит к нулю, и ОС исправляет дисковое пространство.
Я думаю, что причина состоит в том, что, когда крон умирает, у Вас все еще есть допустимый дескриптор в файл, таким образом, можно обычно использовать его.. Другими словами, система проверяет Ваши права как раз в то самое время, когда Вы пытаетесь открыть ее, не на каждой операции файла.
Как сказанный Joril, полномочия релевантны, когда файл открыт; они не проверяются после этого.
Помните, что можно создать файл для записи с 400 (или 444, или 000) полномочия на файле. Вам нужно разрешение создать файл в каталоге, конечно, но у Вас может быть доступ для записи к файлу, который никто еще (кроме корня) не может изменить.
Также обратите внимание, что группа может быть установлена по умолчанию путем установки SGID, обдумал каталог содержания:
chmod g+s /home/shared
Все файлы, созданные в каталоге, будут принадлежать группе, которая владеет /home/shared пока группа не изменяется. На MacOS X, ведет себя система, как будто SGID укусил, был установлен на каждом каталоге - когда файл копируется в каталог, группа установлена на группу, которая владеет каталогом.