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

Я использую archlinux x64. Я изучаю веб-разработку и для редактирования файлов, обслуживаемых Apache в каталоге srv/http , в котором работает Apache, я создал группу, добавляющую моего пользователя и пользователя Apache, чтобы я мог редактировать файлы без необходимости перемещать их между каталогами.
Дело в том, что я могу правильно редактировать файлы в каталоге с моим пользователем, но всякий раз, когда я их сохраняю, пользователь и группа возвращаются к моему пользователю и группе. Например:

 Me: user1:users Apache: http:http Directory ownership: http:development 

Затем я открываю файл /srv/http/index.html с моим пользователем, который выглядит так …
rw-rwr-- 1 http development 1034 Mar 20 20:48 index.html
(поскольку вы можете видеть, что у него есть права на чтение и запись для владельца и для группировки), и когда я его сохраняю, разрешения на файлы возвращаются к этому …
rw-rw-r-- 1 user1 users 1034 Mar 20 20:48 index.html

Я не понимаю, что происходит, если я набираю groups для просмотра своих активных групп пользователей, я получаю это приложение для lp wheel network video audio storage users development где, по сути, говорит, что я являюсь участником разработки. Я думаю, что-то еще.
Может ли кто-нибудь рассказать мне, что происходит, и как я могу исправить это во время сбережения?
Я знаю, что это не большая проблема, но я хочу ее исправить, прежде чем я получу потерянную дефисную проблему.

PD – я использую возвышенный редактор, если дело.

2 Solutions collect form web for “Изменения владельца файла после редактирования редактируемого файла группы”

В UNIX только root может изменить владельца файлов. Как следствие, мы можем заключить, что владелец файла не меняется, когда вы его редактируете. Вместо этого нужно, чтобы ваш редактор записывал отредактированное содержимое в новый файл и заменял старый файл новым. Поскольку это новый файл, файл заканчивается тем, что вы являетесь владельцем.

Вот некоторые преимущества для обновления файлов таким образом:

  • Это атомный: читатели всегда видят старую версию или новую версию, а не частично написанную новую версию.
  • Легче оправиться от ошибок. Если возникает ошибка, такая как заполнение диска, просто удалите новый временный файл (прежде чем переименовать его поверх старой версии), чтобы откат. Если вы обновляете файл на месте, вы можете остаться не в состоянии завершить и обновить, а также не сможете вернуться назад.
  • Вы можете «обновить» файл, к которому у вас нет доступа на запись (потому что вы никогда не пишете старый файл).
  • Любые пользователи, все еще имеющие открытый файл, могут продолжать использовать старую версию столько, сколько им нужно, поэтому они не будут нарушены. Полезно для исполняемых файлов!

Есть и недостатки:

  • Требуется разрешение на запись в каталоге, в котором находится файл (или, по крайней мере, где-то еще в одной файловой системе), чтобы создать в нем новый временный файл, а затем переименовать этот временный файл.
  • Вы не можете сохранить владельца файла, и вы можете или не сможете сохранить его группу.
  • Существует длинный список стилей, который вы можете сохранить, копируя их в новом временном файле, прежде чем перемещать его на место, например, разрешения, расширенные атрибуты, независимо от того, является ли файл символической ссылкой на фактический файл в другом месте, ресурсные вилки (MacOS) и т. д. Если вы не очень осторожны и очень исчерпывающими, трудно не пропустить один или несколько из них.

Так что это компромисс.

Автоматизированные задачи, такие как фоновые сценарии, установка программного обеспечения и т. П., Обычно выбирают замену старой версии новым файлом, особенно из-за атомарности.

Текстовые редакторы и другие человеческие задачи обычно выбирают для редактирования файла на месте.

Я не знаком с вашим редактором, но, похоже, делает противоположный выбор, который делают большинство других редакторов. Вам нужно будет увидеть, можете ли вы сконфигурировать его, чтобы прекратить это делать.


Кстати, на самом деле гораздо лучше, если владелец файлов внутри вашего корня документа принадлежит вам, а не пользователю apache. Это обеспечивает большую уверенность в том, что веб-сервер (если он скомпрометирован, например) не может редактировать файлы. Поэтому вы можете не обращать внимания на эту «проблему» и считаете ее хорошей.

Да, некоторые редакторы в основном удаляют старый файл с новым отредактированным файлом. Таким образом, владелец – это тот, который сделал редактирование, и группа будет вашей основной группой.

Тем не менее, вы принудительно применяете группу к файлам в каталоге, изменяя разрешения каталога с помощью chmod g+s . …. это приведет к тому, что любой вновь созданный файл будет находиться в той же группе, что и каталог, даже если это НЕ ваша основная группа.

Еще один недостаток в использовании разрешений для записи групп – это то, что вы должны изменить свой umask как минимум на 002, чтобы он создавал файлы для записи в группах.

  • NFSv3, отображение GID в гетерогенных Unix-системах
  • пользователь без полномочий root, способный получать доступ к сетевым командам, используя команды?
  • Как включить chrooted доступ SFTP к файлу в RHEL 6.5?
  • Отрицательный GID в / etc / passwd?
  • Вложенные группы POSIX в Linux
  • Как исправить «updatedb: не удается найти группу« mlocate »? На entware?
  • Дайте пользователю разрешение на одну папку
  • предоставить групповые разрешения конкретному устройству
  • postfix expand ldap group И впоследствии разрешить псевдоним
  • Безопасная работа LAMP под конкретным пользователем
  • Tomcat не смог создать файл в каталоге, принадлежащем той же группе
  • Linux и Unix - лучшая ОС в мире.