Co faktycznie zachowuje flaga tar -p (zachowaj uprawnienia)?

Co tak -pnaprawdę zachowuje flaga podczas tworzenia i rozpakowywania tarballa? Czy to rwxuprawnienia, które zachowuje?

Kiedy utworzyłem plik htdocs/archiwalny należący do roota, rozpakowanie go na mój komputer lokalny zmieniło własność z root na mojego użytkownika.

Własność i uprawnienia to dwie różne rzeczy. -pFlaga zachowuje uprawnienia . W systemach * nix zwykli użytkownicy nie mogą zmienić właściciela pliku na użytkownika, który nie jest sobą.

Jak wyjaśniono tutaj :

Tylko procesy o efektywnym identyfikatorze użytkownika równym identyfikatorowi użytkownika pliku lub z odpowiednimi uprawnieniami mogą zmienić własność pliku. Jeśli _POSIX_CHOWN_RESTRICTED obowiązuje dla ścieżki:

• Zmiana ID użytkownika jest ograniczona do procesów z odpowiednimi uprawnieniami.

• Zmiana identyfikatora grupy jest dozwolona dla procesu o efektywnym identyfikatorze użytkownika równym identyfikatorowi użytkownika pliku, ale bez odpowiednich uprawnień, tylko wtedy, gdy właściciel jest równy identyfikatorowi użytkownika pliku lub (uid_t) -1 i grupa jest równa albo do efektywnego identyfikatora grupy procesu wywołującego, albo do jednego z dodatkowych identyfikatorów grupy.

Uzasadnienie tego zostało dobrze wyjaśnione przez @Gilles w tej odpowiedzi na Unixa i Linuksa:

Powodem tego ograniczenia jest to, że przekazanie pliku innemu użytkownikowi może pozwolić na złe rzeczy w rzadkich, ale wciąż ważnych sytuacjach. Na przykład:

• Jeśli system ma włączone przydziały dysku, Alice mogłaby utworzyć plik do zapisu w świecie w katalogu dostępnym tylko dla niej (aby nikt inny nie mógł uzyskać dostępu do tego katalogu do zapisu w świecie), a następnie uruchomić chown, aby plik ten był własnością innego użytkownika Billa . Plik byłby wtedy wliczany do limitu dysku Billa, nawet jeśli tylko Alice może go użyć.
• Jeśli Alice oddaje plik Billowi, nie ma śladu, że Bill go nie utworzył. Może to stanowić problem, jeśli plik zawiera nielegalne lub w inny sposób naruszające dane dane.
• Niektóre programy wymagają, aby ich plik wejściowy należał do konkretnego użytkownika w celu uwierzytelnienia żądania (na przykład plik zawiera instrukcje, które program wykona w imieniu tego użytkownika). Zwykle nie jest to bezpieczny projekt, ponieważ nawet jeśli Bill stworzył plik zawierający poprawne składniowo instrukcje, być może nie zamierzał ich wykonać w tym konkretnym czasie. Niemniej jednak pozwolenie Alicji na utworzenie pliku z dowolną zawartością i pobranie go jako danych wejściowych od Billa może tylko pogorszyć sytuację.

Tak więc, nawet jeśli użyjesz --same-ownerflagi tar , nadal będziesz musiał wyodrębnić pliki, rootaby zachować własność. Ta flaga jest domyślnie włączona root, więc chcesz:

sudo tar xpf foo.tgz

Ciekawe są jeszcze 2 opcje smoły:

--same-owner
       try extracting files with the same ownership as exists in the ar‐
       chive (default for superuser)

--no-same-owner
       extract files as yourself (**default for ordinary users**)

Drugi jest domyślny, więc możesz dodać, --same-owneraby zapisać użytkownika. Prawdopodobnie będziesz musiał to zrobić sudo.

Poza tym: to będzie działać tylko na systemach obsługujących POSIX. A systemy operacyjne inne niż Ubuntu mogą nie mieć tych 2 opcji (nie są standardowe).

Aby zachować właściciela, uruchom go jako root lub użyj flagi --same-owner obok flagi -p podczas wypakowywania.