Co jest takiego specjalnego w pozwoleniu na Linuksa 004?


23

Czytałem Practical Unix i Internet Security , kiedy natknąłem się na następujące wiersze, których nie mogłem zrozumieć.

Jeśli korzystasz z serwera archiwum wu, możesz go skonfigurować w taki sposób, aby przesyłane pliki były przesyłane w trybie 004 , więc nie można ich pobrać przez innego klienta . Zapewnia to lepszą ochronę niż zwykłe uniemożliwienie odczytu katalogu , ponieważ zapobiega przesyłaniu plików, a następnie podawaniu znajomym dokładnej nazwy pliku do pobrania.

Zgoda 004 odpowiada -------r--. Nie można pobrać pliku, jeśli ma on dostęp do odczytu? A także, dlaczego uważa się to za lepsze niż zwykłe uczynienie katalogu nieczytelnym? Co to oznacza?

Uwaga: dotyczy to nieautoryzowanych użytkowników pozostawiających nielegalne i chronione prawem autorskim materiały na serwerach korzystających z anonimowego FTP. Powyższe rozwiązanie zostało zasugerowane, aby temu zapobiec wraz ze skryptem, który usuwa zawartość katalogu po pewnym czasie.


W szczególności wygląda na to, że odwołuje się do WU-FTP , o sławie wuarchive.wustl.edu.
Parthian Shot

2
tutaj chodzi o UMASK 004, a nie pozwolenie!
Afsin Toparlak,

3
@AfsinToparlak nie, to zdecydowanie pozytywne pozwolenie, a nie umask. Zobacz zaakceptowaną odpowiedź.
o11c

„Nie można pobrać pliku, jeśli ma on dostęp do odczytu” To nie do końca poprawne. Każdy oprócz użytkownika i grupy będącej właścicielem pliku ma dostęp do odczytu.
scai

1
W odniesieniu do „ Zapewnia to lepszą ochronę niż zwykłe uczynienie katalogu nieczytelnym, ponieważ uniemożliwia to przesyłanie plików, a następnie podawanie znajomym dokładnej nazwy pliku do pobrania. ”… Wcześniejszą sztuczką było uczynienie obszaru przesyłania czymś w rodzaju 333( lub d-wx-wx-wx), które pozwalają użytkownikom (użytkownikom FTP) tworzyć pliki, ale ponieważ nie ma uprawnień do odczytu [w katalogu], nie mogą wyświetlić plików w katalogu przesyłania. Jeśli jednak znasz nazwę, możesz odczytać / pobrać pliki.
TripeHound,

Odpowiedzi:


33

Uprawnienia 004 (------ r--) oznaczają, że plik może być odczytany tylko przez procesy, które nie są uruchomione jako ten sam użytkownik lub ta sama grupa co serwer FTP. Jest to raczej niezwykłe: zwykle użytkownik ma więcej uprawnień niż grupa, a grupa ma więcej uprawnień niż inne. Zwykle użytkownik może zmienić uprawnienia, więc nie ma sensu udzielać użytkownikowi bardziej restrykcyjnych uprawnień. Ma to sens, ponieważ serwer FTP (prawdopodobnie) nie ma polecenia zmiany uprawnień, więc pliki zachowają swoje uprawnienia, dopóki coś innego ich nie zmieni.

Ponieważ użytkownik, na którym działa serwer FTP, nie może odczytać plików, ludzie nie będą mogli go pobrać. To uniemożliwia użycie serwera FTP do udostępniania pliku.

Prawdopodobnie jakiś proces działający jako inny użytkownik i grupa czyta plik w pewnym momencie, sprawdza, czy jest zgodny z pewną polityką, kopiuje dane, jeśli tak, i usuwa przesłany plik.

Bardziej sensowniejsze byłoby dla mnie przyznanie uprawnień do pliku 040 (czytelnych tylko dla grupy) i spowodowanie, aby proces klienta działał jako ta sama grupa co serwer FTP, ale inny użytkownik.


1
@Cthulhu: Proces serwera FTP należy również do „wszystkich”. Ale uprawnienia UNIX nie są przeszukiwane. Rozważana jest tylko jedna trojga praw, a jest to kontrola pozytywna / negatywna. (W przeciwieństwie do
list

8

Ośmiokrotna maska ​​uprawnień 004odpowiada symbolicznej masce uprawnień, u=,g=,o=rktóra oznacza, że (u)serwłaściciel pliku nie może go odczytać, zapisać ani wykonać, ani też inni użytkownicy nie mogą być tym samym (g)roupużytkownikiem, co właściciel pliku. Tylko (o)therużytkownicy, którzy nie są ani właścicielem, ani w tej samej grupie co właściciel, mogą odczytać plik.


1
tutaj chodzi o UMASK 004, a nie pozwolenie!
Afsin Toparlak,

4
@AfsinToparlak: nie, jest to wyraźne zezwolenie . Zobacz zaakceptowaną odpowiedź.
TripeHound,

6

Tak, ale plik jest własnością użytkownika. Sam klient ma więc uprawnienie 0 (użytkownik) do pliku i nie może go odczytać.

Możesz to przetestować samodzielnie:

echo TEST > myTestFile;
chmod 004 myTestFile;
cat myTestFile;
chmod 700 myTestFile;
cat myTestFile;

Trzeci krok spowoduje błąd.


Więc kiedy plik jest przesyłany, tylko ten użytkownik otrzymuje uprawnienia do odczytu pliku, a wszyscy inni otrzymują 000? Mam rację? Czy możesz rozszerzyć swoją odpowiedź?
Aswin PJ,

1
Znalazłem książkę, a rozdział dotyczy zabezpieczenia publicznego katalogu, który można zapisać dla anonimowych klientów ftp. Każdy anonimowy klient otwiera plik jako ten sam identyfikator użytkownika, co każdy inny anonimowy klient, więc utworzony plik można utworzyć anonimowo, ale nie można go odczytać przez anonimowego. Jest czytelny dla dowolnego innego identyfikatora użytkownika w systemie.
Jodka Lemon

@hope: każda cyfra w łańcuchu ósemkowym zezwolenia reprezentuje 4 bity: set-id, read, write i exec, w tej kolejności. Zatem 7 oznacza, że ​​bity odczytu, zapisu i wykonania są ustawione. Pierwsza cyfra to pozwolenie właściciela itp. Nie ma więc sensu mówić, że inni dostają 000. Inne są po prostu 0. Odpowiedź Gillesa jest najlepszym wytłumaczeniem tego, co 004faktycznie robi ustawienie uprawnień .
Peter Cordes,

Trzecim krokiem jest pisanie, a nie czytanie.
Stop Harming Monica,

@OrangeDog Masz rację. Poprawiłem to.
Jodka Lemon

-1

Wydaje się bardziej prawdopodobne, że oznacza to, że wszelkie uprawnienia są maskowane przez 004, co oznacza, że ​​inni użytkownicy nie mogą odczytać pliku. Służyłoby to do ochrony pliku przed innymi użytkownikami w systemie (do pewnego stopnia).


Nie, jak wyjaśnili inni, serwer ftp ustawia uprawnienia, aby 004użytkownik, który go przesłał, oraz inni użytkownicy ftp (przynajmniej anonimowi) nie mogli uzyskać dostępu do pliku, dopóki nie zostanie sprawdzony (kiedy zostanie ponownie autoryzowany i prawdopodobnie przeniesiony / przemianowany w odpowiednie miejsce). Miejsca takie jak Archiwum WU były często (źle) używane w ciemnej i odległej przeszłości jako witryny do udostępniania plików, jeśli takie rzeczy nie zostały wprowadzone.
TripeHound,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.