Comment conserver la propriété d'un fichier après sa modification?

Ma question est similaire à cette autre , sauf que l'on pose des questions sur les fichiers nouvellement créés.

Dans ma boîte Unix, les utilisateurs alice , bob et tomcat sont dans le groupe tomcat .

Les fichiers de configuration du serveur Tomcat appartiennent à l'utilisateur tomcat et au groupe tomcat.

J'ai changé les autorisations de ce fichier en lisible et en écriture par groupe afin qu'Alice et Bob puissent éditer les fichiers.

Cependant, j'ai remarqué qu'après la modification, le fichier appartient au dernier utilisateur qui l'a modifié.

Q: Est-il possible de modifier les autorisations pour qu'Alice et Bob puissent modifier les fichiers, sans changer de propriétaire?

Comment la modification d'un fichier change-t-elle de toute façon sa propriété?

L'utilisateur résultant du fichier dépend de ce que fait l'éditeur. Certains éditeurs enregistrent le fichier en le tronquant et en écrivant sur le fichier (sans changer l'inode). Et certains éditeurs renomment le fichier sous un autre nom ( fileà file~est habituel) et créent un nouveau fichier avec le nom de l'original. La modification du fichier d'origine conserve le même propriétaire, la création d'un nouveau fait que le nouveau fichier appartient à l'UID du processus de création.

Parmi les éditeurs que j'ai sur Debian, nanoet joeaussi ( nviet vimla version minimale en vim-tiny) semblent écraser sur place. Bien que je suppose vimet Emacs sont probablement configurables dans ce qu'ils font.

Stephen commente les mises à jour atomiques . Le problème avec la recréation sur place est que le fichier est tronqué à zéro, puis écrit. Un autre processus pourrait l'ouvrir et le lire avant que toutes les données soient écrites.

Une mise à jour atomique serait fait en créant la nouvelle version par exemple file.new, puis renommer file.newà file. Laisser un fichier de sauvegarde, on pourrait créer file.new, lien filevers file~puis renommer file.newà file. Le renommage est atomique dans la mesure où tout processus qui accède au fichier par son nom obtient l'ancienne ou la nouvelle version, rien entre les deux. Tout descripteur de fichier ouvert pointera bien sûr vers le fichier qui a été maintenu ouvert, donnant une vue cohérente sur le fichier.

Du point de vue des autorisations de fichier , l'enregistrement sur le même fichier (inode) nécessite un accès en écriture au fichier lui-même (mais pas au répertoire), le renommer et en créer un nouveau nécessite un accès en écriture au répertoire (mais pas au fichier d'origine) ).

(Renommer et recréer est également un moyen de corriger les autorisations de fichier au cas où quelqu'un crée ou modifie un fichier dans un répertoire partagé, mais oublie de lui donner un accès en écriture par le groupe.)

Comme expliqué par ilkkachu , si l'éditeur utilisé crée un nouveau fichier lors de l'enregistrement, il n'y a aucun moyen de contrôler le propriétaire du fichier. Cependant, ce qui vous tient à cœur, c'est de vous assurer que les fichiers restent lisibles par Tomcat; vous pouvez le faire en vous assurant que leur groupe est tomcat(et qu'ils sont lisibles par leur groupe), et que cela peut être appliqué sur les nouveaux fichiers en définissant le setgidbit sur le répertoire parent :

chmod g+s .

Ainsi, si bobédite un fichier à l'aide d'un éditeur qui recrée le fichier, le fichier édité finira par appartenir à bob:tomcatTomcat et pourra toujours le lire (avec un typique umaskau moins). Tant que le répertoire parent est accessible en écriture par le tomcatgroupe, tout utilisateur de ce groupe pourra éditer les fichiers du répertoire (ne serait-ce qu'en les recréant).

Je recommanderais cependant de chercher à changer vos processus; vous ne devriez probablement pas modifier les fichiers directement à l'emplacement où ils sont lus par Tomcat. Idéalement, les fichiers seraient conservés dans un VCS quelconque et déployés par un processus distinct (éventuellement automatisé). De cette façon, vous évitez tous ces problèmes de propriété ...