Dlaczego rm może usuwać plik będący własnością innego użytkownika?

Z postu Dlaczego rm może usuwać pliki tylko do odczytu? Rozumiem, że rmpo prostu potrzebuje uprawnienia do zapisu w katalogu, aby usunąć plik. Ale trudno mi zrozumieć zachowanie, w którym możemy łatwo usunąć plik, którego właściciel i grupa są inni.

Próbowałem następujące

mtk: moja nazwa użytkownika
abc: utworzył nowego użytkownika

$ ls -l file
-rw-rw-r-- 1 mtk mtk       0 Aug 31 15:40 file
$ sudo chown abc file
$ sudo chgrp abc file
$ ls -l file
-rw-rw-r-- 1 abc abc       0 Aug 31 15:40 file
$ rm file
$ ls -l file
<deleted>

Myślałem, że to nie powinno być dozwolone. Czy użytkownik powinien mieć możliwość usuwania tylko swoich plików? Czy ktoś może wyjaśnić, dlaczego jest to dozwolone? i jak można tego uniknąć? Mogę myśleć tylko o ograniczeniu uprawnień do zapisu katalogu nadrzędnego, aby uniemożliwić zdziwione usuwanie pliku.

files permissions rm history architecture Mt.
źródło

Odpowiedzi:

100

Powód, dla którego jest to dozwolone, jest związany z faktycznym usuwaniem pliku. Koncepcyjnie, rmzadaniem jest usunięcie wpisu nazwy z katalogu. Fakt, że plik może wtedy stać się nieosiągalny, jeśli była to jedyna nazwa pliku, i że w związku z tym można odzyskać i-węzeł i przestrzeń zajmowane przez plik w tym momencie, jest prawie przypadkowe. Nazwa wywołania systemowego wywoływanego przez to rmpolecenie unlink, nawet sugeruje ten fakt.

I usunięcie wpisu nazwy z katalogu jest zasadniczo operacją na tym katalogu , więc ten katalog jest tym, czego potrzebujesz, aby mieć uprawnienia do zapisu.

Poniższy scenariusz może sprawić, że poczujesz się bardziej komfortowo? Załóżmy, że istnieją katalogi:

/home/me    # owned and writable only by me
/home/you   # owned and writable only by you

I jest plik, który jest własnością mnie i który ma dwa twarde linki:

/home/me/myfile
/home/you/myfile

Nieważne, jak ten twardy link /home/you/myfilesię tam znalazł. Może rootto tam umieść.

Idea tego przykładu polega na tym, że powinieneś mieć możliwość usunięcia twardego linku /home/you/myfile. W końcu zaśmieca twój katalog. Państwo powinno być w stanie kontrolować tego, co robi i nie istnieje wewnątrz /home/you. A kiedy usuniesz /home/you/myfile, zauważ, że tak naprawdę nie usunąłeś pliku. Usunąłeś tylko jeden link do niego.

Zauważ, że jeśli lepki bit jest ustawiony na katalogu zawierającego plik (pokazuje się jak tw ls), to nie trzeba być właścicielem pliku, aby móc go usunąć (chyba, że jesteś właścicielem katalogu). Lepki bit jest zwykle włączony /tmp.

Celada
źródło

Z lepkim bitem w katalogu musisz mieć możliwość modyfikacji pliku, aby móc go usunąć. Oznacza to, że jeśli plik należy do kogoś innego w tej samej grupie, co Ty, a grupa może zapisać plik, możesz go usunąć. Następstwo: każdy może usunąć plik z publicznym zezwoleniem na zapis. (Wszyscy oczywiście mogą modyfikować katalog.)

Jonathan Leffler

Być może źle cię interpretuję, ale czy nie mówisz, że mogę usunąć go -rw-rw-rw- 1 root root 0 Sep 1 11:11 /tmp/foojako zwykłego użytkownika ( /tmpjest on „lepki”), ponieważ mogę go napisać? Ale nie mogę.

Celada

Uważam, że scenariusz me/ youstaje się bardziej wyraźny, jeśli postawisz hipotezę, że użytkownik (ten, który nie jest właścicielem pliku) utworzył łącze. Zaimki są trudne w użyciu; powiedzmy, że Al tworzy /home/al/file1, a Bob, który ma dostęp (i może odczyt) do dostępu /home/al, łączy go z plikiem /home/bob/als_file. Bob powinny być zabezpieczone przed usunięciem linku który on stworzył? I czy Al powinien mieć możliwość usuwania (odłączania), /home/bob/als_filegdy nie ma dostępu do zapisu /home/bob? Ta droga prowadzi do chaosu.

Scott

@JathanathanLeffler: Jak pokazuje przykład Scotta, nie, rozłączanie i obcinanie nie daje tego samego wyniku netto, gdy w grze występują twarde linki.

Kevin

@Kevin Myślę, że chodzi o to, że jeśli ktoś ma uprawnienia do zapisu do pliku, aby mógł zniszczyć zawartość, to równie dobrze może mieć prawo do rozłączenia go (zakładając, że ma również uprawnienia do zapisu do katalogu). Nie dotyczy to odwrotności - możliwość usunięcia pliku z jednego katalogu nie oznacza, że powinien on być w stanie zniszczyć zawartość, ponieważ mogą one być dostępne z innego katalogu. Taka jest logika działania lepkiego bitu.

Barmar

Aby usunąć plik, wystarczy mieć możliwość zapisu do katalogu, w którym znajduje się plik.

Jeśli ci się to nie podoba, możesz ustawić „lepki” bit, chmod +t dirjeśli jesteś w połowie systemu operacyjnego (ta funkcja została wprowadzona około 1986 roku w SunOS).

Jeśli chcesz być bardziej precyzyjny, potrzebujesz systemu plików z nowoczesną implementacją ACL, taką jak ZFS. Standardowe listy ACL NFSv4 oparte na systemie plików NTFS obejmują obsługę specyficznych dla plików uprawnień do usuwania na użytkownika oraz uprawnienie „delete_child” dla katalogów.

schily
źródło

Pamiętaj, że aby dodać tbit, musisz posiadać katalog. A jeśli jesteś właścicielem katalogu, zawsze możesz usunąć pliki bez względu na to, czy tbit jest ustawiony, czy nie. Jeśli podłączysz plik do katalogu innej osoby, powinieneś być przygotowany na to, aby ktoś mógł go usunąć. Alternatywą byłoby najpierw utworzenie własnego podkatalogu i dodanie tam pliku, ponieważ właściciel nie byłby w stanie usunąć tego podkatalogu, jeśli nie jest pusty.

Stéphane Chazelas,

Opisujesz sytuację w sposób wprowadzający w błąd. Technicznie rzecz biorąc, pliku nie ma w katalogu; raczej nazwa pliku znajduje się w katalogu i rmjest operacją w katalogu, a nie w pliku. Plik zostanie usunięty po usunięciu ostatniego odwołania do niego, ale technicznie jest to efekt uboczny.

reinierpost

Logika jest podobna do logiki domu: właściciel lub najemca decyduje, których gości wyrzucić, bez względu na to, kto jest ich właścicielem. Ponadto eksmitowany gość, który jest mile widziany w innym domu (ma inny link w katalogu innej osoby), nie zamarznie na zewnątrz.

rackandboneman
źródło