Мой вопрос похож наэтот другой, за исключением того, что спрашивается о вновь созданных файлах.
В моем Unix-боксе пользователиалиса,бобиКотв группеКот.
Файлы конфигурации сервера Tomcat принадлежат пользователю tomcat и находятся в группе tomcat.
Я изменил права доступа к этому файлу, разрешив его чтение и запись группе, чтобы Алиса и Боб могли редактировать файлы.
Однако я заметил, что после редактирования файл становится собственностью последнего пользователя, который его редактировал.
В:Можно ли изменить права доступа так, чтобы Алиса и Боб могли редактировать файлы, не меняя своих владельцев?
Каким образом редактирование файла меняет его владельца?
решение1
Полученный пользовательфайла зависит от того, что делает редактор. Некоторые редакторы сохраняют файл, обрезая его и записывая поверх файла (не изменяя inode). А некоторые редакторы переименовывают файл в другое имя ( обычно fileto file~) и создают новый файл с именем оригинала. Изменение оригинального файла сохраняет владельца тем же, создание нового делает новый файл владельцем UID процесса создания.
Из редакторов, которые у меня есть на Debian, nanoи joe, а также nviи vim(минимальная версия в vim-tiny), похоже, перезаписывают на месте. Хотя я предполагаю, vimчто и Emacs, вероятно, настраиваются в том, что они делают.
Стивен комментируетатомарные обновления. Проблема с повторным созданием на месте заключается в том, что файл обрезается до нулевой длины, а затем записывается. Другой процесс может открыть и прочитать его до того, как все данные будут записаны.
Атомарное обновление будет выполнено путем создания новой версии, скажем file.new, , а затем переименования file.newв file. Оставив резервный файл, можно создать file.new, связать fileс ним file~и затем переименовать file.newв file. Переименование является атомарным в том смысле, что любой процесс, который обращается к файлу по имени, получает либо старую, либо новую версию, а не что-либо среднее. Любые открытые дескрипторы файлов, конечно, будут указывать на файл, который был открыт, что дает единообразное представление о файле.
Изправа доступа к файламС точки зрения сохранения, для сохранения того же файла (inode) требуется доступ на запись к самому файлу (но не к каталогу), для его переименования и создания нового файла требуется доступ на запись к каталогу (но не к исходному файлу).
(Переименование и повторное создание также, кстати, является способом исправления прав доступа к файлу на случай, если кто-то создаст или изменит файл в общем каталоге, но забудет предоставить группе право записи в него.)
решение2
Какобъяснилкилккачу, если используемый редактор создает новый файл при сохранении, то нет возможности контролироватьвладелецфайла. Однако, что вас, вероятно, действительно волнует, так это обеспечение того, чтобы файлы оставались доступными для чтения Tomcat; вы можете сделать это, обеспечив их группу tomcat(и их доступность для чтения их группой), и это можно применить к новым файлам, установив бит setgidна родительскомкаталог:
chmod g+s .
Таким образом, если bobредактировать файл с помощью редактора, который пересоздает файл, то отредактированный файл в конечном итоге станет собственностью bob:tomcatи Tomcat по-прежнему сможет его прочитать ( umaskпо крайней мере, с типичным разрешением). Пока родительский каталог доступен для записи tomcatгруппе, любой пользователь в этой группе сможет редактировать файлы в каталоге (хотя бы путем их пересоздания).
Однако я бы рекомендовал рассмотреть возможность изменения ваших процессов; вам, вероятно, не следует редактировать файлы непосредственно в том месте, откуда их считывает Tomcat. В идеале файлы должны храниться в VCS какого-либо вида и развертываться отдельным процессом (возможно, автоматизированным). Таким образом, вы избежите всех этих проблем с владением...