Jak zachować własność pliku po edycji?

Moje pytanie jest podobne do tego drugiego , z tym wyjątkiem, że pytamy o nowo utworzone pliki.

W moim systemie uniksowym użytkownicy alice , bob i tomcat są w grupie tomcat .

Pliki konfiguracyjne serwera Tomcat są własnością użytkownika tomcat oraz w grupie tomcat.

Zmieniłem uprawnienia tego pliku do odczytu i zapisu według grup, aby alice i bob mogli edytować pliki.

Zauważyłem jednak, że po edycji plik staje się własnością ostatniego użytkownika, który go edytował.

P: Czy można zmienić uprawnienia, aby Alice i Bob mogli edytować pliki bez zmiany ich własności?

W jaki sposób edycja pliku zmienia jego własność?

Wynikowy użytkownik pliku zależy od czynności edytora. Niektóre edytory zapisują plik, obcinając go i zapisując nad plikiem (bez zmiany i-węzła). A niektórzy redaktorzy zmień nazwę pliku na inną nazwą ( fileaby file~to zwykle bywa) i utworzyć nowy plik o nazwie oryginału. Modyfikacja oryginalnego pliku nie zmienia właściciela, tworzenie nowego powoduje, że nowy plik jest własnością UID procesu tworzenia.

Z redaktorów Mam na Debianie, nanoa joe, a nvi, a vim(minimalna wersja vim-tiny) wydają się zastąpić w miejscu. Chociaż przypuszczam, że vimEmacsa można konfigurować w tym, co robią.

Stephen komentuje aktualizacje atomowe . Problem z ponownym tworzeniem w miejscu polega na tym, że plik jest obcinany do zerowej długości, a następnie zapisywany. Inny proces może zostać otwarty i odczytany przed zapisaniem wszystkich danych.

Aktualizacja atomowa zostałaby wykonana przez utworzenie nowej wersji, jak powiedzmy file.new, a następnie zmianę nazwy file.newna file. Pozostawiając plik kopii zapasowej, można utworzyć file.new, połączyć filesię, file~a następnie zmienić nazwę file.newna file. Zmiana nazwy ma charakter atomowy, ponieważ każdy proces, który uzyskuje dostęp do pliku według nazwy, otrzymuje zarówno starą, jak i nową wersję, a nie nic pośredniego. Wszelkie otwarte uchwyty plików będą oczywiście wskazywały na plik, który był trzymany otwarty, co zapewnia spójny widok pliku.

Z punktu widzenia uprawnień do plików zapisanie tego samego pliku (i-węzła) wymaga dostępu do zapisu do samego pliku (ale nie do katalogu), zmiana jego nazwy i utworzenie nowego wymaga zapisu do katalogu (ale nie do oryginalnego pliku ).

(Zmiana nazwy i odtwarzanie jest zresztą okazjonalnie sposobem ustalenia uprawnień do plików na wypadek, gdyby ktoś utworzył lub zmodyfikował plik we współdzielonym katalogu, ale zapomniał przyznać grupie uprawnienia do zapisu).

Jak wyjaśniono przez ilkkachu , jeśli redaktor wykorzystywane tworzy nowy plik podczas zapisywania, to nie ma sposobu kontrolowania właściciela pliku. To, co prawdopodobnie naprawdę Cię obchodzi, to zapewnienie czytelności plików przez Tomcat; możesz to zrobić, upewniając się, że ich grupa jest tomcat(i są czytelne dla ich grupy), i że można to wymusić w nowych plikach, ustawiając setgidbit w katalogu nadrzędnym :

chmod g+s .

Tak więc, jeśli bobedytuje plik przy użyciu edytora, który ponownie go tworzy, edytowany plik stanie się własnością bob:tomcati Tomcat nadal będzie mógł go odczytać ( umaskprzynajmniej w typowy sposób ). Tak długo, jak katalog nadrzędny jest zapisywalny przez tomcatgrupę, każdy użytkownik w tej grupie będzie mógł edytować pliki w katalogu (choćby przez ich ponowne utworzenie).

Poleciłbym jednak zastanowić się nad zmianą procesów; prawdopodobnie nie powinieneś edytować plików bezpośrednio w lokalizacji, z której czytają je Tomcat. Najlepiej byłoby, gdyby pliki były przechowywane w jakimś VCS i wdrożone przez osobny proces (ewentualnie zautomatyzowany). W ten sposób unikniesz wszystkich problemów związanych z własnością ...