Wady Umask 077?


15

Jakie są wady za restrykcyjne umask 077? Wiele dystrybucji (uważam, że wszystkie oprócz Red Hat?) Mają domyślną umaskę 022, skonfigurowaną w / etc / profile. Wydaje się to zbyt niepewne w przypadku systemu innego niż stacjonarny, do którego uzyskuje dostęp wielu użytkowników, a bezpieczeństwo budzi obawy.

W powiązanej notatce, w Ubuntu, katalogi domowe użytkowników są również tworzone z uprawnieniami 755, a instalator stwierdza, że ​​ułatwia to użytkownikom udostępnianie plików. Zakładając, że użytkownicy wygodnie ustawiają ręcznie uprawnienia do udostępniania plików, nie stanowi to problemu.

Jakie są inne wady?


uprawnienia wydają się bardziej podobne niż „umask” dla tagów ... imo
xenoterracide

Możesz mieć do 5 tagów na pytanie, więc po co o to walczyć? :) Dodano tag umask.
Warren Young,

@ warren, bo nie sądzę, że potrzebujemy tagów dla każdego właściwego rzeczownika. kiedy mówisz o uprawnieniach w unixie, musisz dołączyć umask.
ksenoterrakid

Odpowiedzi:


15

022 sprawia, że ​​wszystko jest wygodne. 077 sprawia, że ​​rzeczy są mniej wygodne, ale w zależności od okoliczności i profilu użytkowania może nie być mniej wygodne niż korzystanie sudo.

Twierdziłbym sudo, że faktyczna, mierzalna korzyść z bezpieczeństwa, którą zyskujesz, jest znikoma w porównaniu z poziomem bólu, jaki wyrządzasz sobie i swoim użytkownikom. Jako konsultant byłam lekceważona za moje poglądy sudoi prowokowana do przełamania wielu sudokonfiguracji, i muszę jeszcze poświęcić na to ponad 15 sekund. Twoja decyzja.

Wiedza o tym umaskjest dobra, ale to tylko jeden płatek kukurydziany w „pełnym śniadaniu”. Być może powinieneś zadać sobie pytanie: „Zanim przejdę do zrzucania domyślnych konfiguracji, których spójność będzie musiała być utrzymywana w różnych instalacjach, i które będą musiały być udokumentowane i uzasadnione dla osób, które nie są przyćmione, co to kupi mnie?"

Umask to także wbudowana bash, którą indywidualni użytkownicy mogą ustawić w swoich plikach inicjalizacyjnych powłoki ( ~/.bash*), więc tak naprawdę nie jesteś w stanie łatwo wymusić umask. To tylko domyślne. Innymi słowy, to niewiele kupuje.


2

Najbardziej oczywistym minusem jest rozpoczęcie tworzenia plików / katalogów we współdzielonym katalogu, oczekując od innych użytkowników dostępu do nich.

Oczywiście chodzi tylko o to, aby nie zapomnieć ustawić poprawnego umask przed zrobieniem rzeczy, które muszą być udostępnione wszystkim użytkownikom.

Kolejnym zastrzeżeniem (nie jest to naprawdę wada, gdy się o tym wiesz), kiedy zaczynasz robić rzeczy sudo, takie jak instalowanie lokalnych programów, ruby ​​gems, pythonowe jaja (oczywiście nie zarządzają pakietami), tworzenie plików konfiguracyjnych i tak dalej.

Wpadniesz w kłopoty, ponieważ umask jest dziedziczony przez sesję sudo, więc tylko root będzie miał dostęp do plików / katalogów, które utworzysz. sudo można skonfigurować tak, aby automatycznie ustawiał umask tak, jak chcesz: to pytanie jest omówione na stronie superuser.com .


a ten drugi powód jest dobrym powodem do su -upewnienia się, że root ma inny umask ... ale och ... ubuntu nie wierzy w root ...
xenoterracide

1
@xenoterracide: sudo su -działa dobrze. Ubuntu, podobnie jak MacOSX, nie wierzy w root, do którego można się po prostu zalogować. Osobiście lubię mówić coś w stylu „Simon Says” dla poleceń roota.
David Thornley,

@xenoterracide eh? o co ci chodzi? zarówno sudo, jak i su pozwalają na rootowanie z innym umask. @David możesz używać sudo -i zamiast sudo su -
zarkdav

1
@xenoterracide: Właściwie użycie polecenia root oznacza, że ​​prawdopodobnie wpisuję coś w niewłaściwym oknie. Użycie „sudo” oznacza, że ​​muszę określić, że chcę to wykonać przez root. Wiem doskonale, że istnieje konto root, więc nie widzę, skąd bierze się fałszywe poczucie bezpieczeństwa. To tylko jeden mały rytuał (jak siedzenie na rękach), który sprawia, że ​​mniej prawdopodobne jest, że zrobię coś śmiertelnie głupiego jako root.
David Thornley,

1
sudo i su są narzędziami, jak każde polecenie. Nie musisz mieszać uczuć z użytecznością. sudo zapewnia elastyczną konfigurację, audyt i użyteczność. Oczywiście trzeba wiedzieć o różnych możliwościach i faktycznie ich potrzebować, aby rozpoznać korzyści. Myślę, że to „fałszywe poczucie bezpieczeństwa”, o którym mówisz, powinno być lepiej ukierunkowane na politykę „wyłączania konta root” Ubuntu. To jest różnica między narzędziem a polityką. Można argumentować przeciwko polityce. Odmowa przydatności narzędzia, ponieważ nie zgadza się z polityką, jest po prostu błędna.
zarkdav

1

Umask nie byłby odpowiedni, jeśli próbujesz kontrolować to, co widzą inni użytkownicy. Jednak jeśli masz i pracujesz z wieloma plikami, które są wrażliwe na to, że proszenie o pozwolenie na dostęp do nich jest mniej uciążliwe / ryzykowne niż tylko pozwalanie ludziom zobaczyć, co chcą, to umask 077 byłby dobrym pomysłem.

Mam kilka poufnych plików na zarządzanym przeze mnie serwerze plików. Myślę, że ustawienie restrykcyjnego umask, a następnie okresowego skryptu, być może zadanie crona w celu ustawienia bardziej szczegółowych uprawnień do elementów w niektórych folderach byłoby dla mnie idealnym rozwiązaniem. Kiedy to skonfiguruję, wyślę z powrotem tutaj i dam znać, jak to działa.

@ [Faceci walą sudo] Rozpocznij nowy wątek, może to zająć kilka własnych wątków, a ten wątek dotyczy umask.


1

Aplikacje innych firm korzystające z własnych systemów instalacyjnych mogą mieć wbudowane założenia dotyczące domyślnego umask systemu.

Jako praktyczny przykład, po zaktualizowaniu bazy danych Oracle 10 w systemie, w którym umask ustawiony jest na 077, aplikacje w tym samym systemie nie uzyskały dostępu do bazy danych ... ponieważ biblioteki niezbędne dla klientów bazy danych oraz katalogi bibliotek znajdowały się w, były teraz chronione, aby tylko oracleużytkownik mógł uzyskać do nich dostęp, co oczywiście nie działało tak, jak powinno.

Okazuje się, że proces aktualizacji Oracle nie zadbał szczególnie o to, aby uprawnienia bibliotek klienckich pozwalały innym użytkownikom na korzystanie z nich, ale opierał się na założeniu, że pliki dodane przez aktualizator zostaną utworzone przy pomocy umask 022 i dlatego będą użyteczne domyślnie. Po kilku rozsądnych chmod -R a+rXpoleceniach dla odpowiednich katalogów wszystko znów było dobrze.

To prawda, że ​​można tego uniknąć, traktując to oraclekonto jako specjalne konto systemowe ze standardowym umask 022 i ograniczając umask 077 tylko do kont użytkowników faktycznie zalogowanych ... ale myślę, że jest to dobry przykład tego, jak koc twardnieje „decyzje mogą mieć nieprzewidziane skutki uboczne.

.rpma .debpakiety zawierają wyraźne informacje o uprawnieniach do wszystkich zawartych w nich plików, więc na ogół nie mają ryzyka wystąpienia błędów tego typu.


0

Mam tę linię w swoim ~/.zshrc

umask 0077

ustawienie go globalnie prawdopodobnie nie jest dobrym pomysłem, ale ustawienie go jako domyślnego w pliku rc prawdopodobnie nie zaszkodzi, a nawet ustawienie go jako domyślnego w /etc/skel/.rcpliku. cały system spowoduje jednak problemy.


0

Spowoduje to problemy na serwerze; na przykład, gdy wiele aplikacji działa jako różni użytkownicy próbujący uzyskać dostęp do plików od różnych użytkowników. Na przykład apache czyta pliki konfiguracyjne lub pi-hole czyta dnsmasq.conf. Po prostu uruchom go na użytkownikach, którzy mogliby z niego korzystać, tak jak w przypadku indywidualnych katalogów domowych, a nie jawnie skonfigurowanych /etc/profile.

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.