VIDEO TRANSCRIPTION
Pasja informatyki
Ubuntu Server #2: Połączenie SSH, użytkownicy, grupy, hasła, uprawnienia do plików i katalogów
Description generated by Skrybot
Omówiono konfigurację szyfrowanego, zdalnego połączenia z wykorzystaniem protokołu SSH oraz zarządzanie użytkownikami i uprawnieniami w systemie Ubuntu. Praca z terminalem została ułatwiona poprzez zdalne połączenie SSH, które jest często wykorzystywane w środowiskach produkcyjnych. Omówiono także konfigurację haseł, politykę haseł, tworzenie nowych użytkowników, dziedziczenie uprawnień, mechanizm bitów specjalnych oraz ustawianie domyślnych uprawnień za pomocą UMASK. Uprawnienia plików i katalogów w Linuxie są nadawane na podstawie ID użytkownika, a nie nazwy.
Transcription generated by Skrybot
DZIĘKI ZA OBSERWACIE W dzisiejszym epizodzie zajmiemy się konfiguracją szyfrowanego, zdalnego połączenia z wykorzystaniem protokołu SSH, a także dowiemy się, jak w Ubuntu zarządzać użytkownikami i uprawnieniami do zasobów. Zanim zaczniemy właściwą pracę z terminalem, przygotujmy sobie system do zdalnego, szyfrowanego połączenia SSH. Takie połączenie, po pierwsze, realizowane jest zazwyczaj w produkcyjnych środowiskach, tam bardzo często jest to jedyny sposób na kontakt z serwerem, bo nie ma możliwości fizycznego z nim obcowania lub możliwość ta jest mocno ograniczona. a po drugie zwyczajnie ułatwia pracę z systemem. Użycie klienta SSH jest zdecydowanie wygodniejsze niż klepanie komend z poziomu maszyny wirtualnej, tak jak było to pokazane w pierwszym odcinku. Dzięki możliwościom, jakie dają nam klienty SSH, możemy kopiować czy też wklejać całe linie poleceń, a także z łatwością przeglądać duże zbiory wyników działania poszczególnych komend, co na wirtualu jest dość mocno ograniczone.
To oczywiście nie jest element niezbędny do dalszej pracy podczas kursu. Jeśli nie macie ochoty pracować za pomocą zdalnego połączenia, to luzik. można się bez tego obejść, chociaż zdecydowanie polecam i zalecam. Usługę SSH realizowaną przez darmowe oprogramowanie OpenSSH mamy już zainstalowaną. Zrobiliśmy to poprzednio w trakcie stawiania systemu. Pozostaje nam jeszcze kilka modyfikacji do wykonania, aby takie połączenie sobie uskutecznić. Na temat samego protokołu SSH opowiadałem już jakiś czas temu przy okazji odcinka o sieciach i protokołach warstwy aplikacji. Z grubsza wyjaśniłem tam jak nawiązywane jest połączenie, no i jak sam protokół działa. Tutaj sobie już teorię odpuścimy i skupimy się tylko na zestawieniu połączenia. Na początek warto sprawdzić, czy na pewno SSH nam działa. W tym celu wydajemy w systemie polecenie systemctl status ssh. Usługa działa. Widać to tutaj.
Jeśli z jakichś powodów usługa nie jest zainstalowana, wystarczy zainstalować ją takim poleceniem. U mnie SSH już pracuje, tak więc możemy działać. Aby połączenie zdalne z serwerem zestawić, potrzebujemy oczywiście jego adres IP. Nasza maszyna ma aż trzy adresy. Pytanie tylko, czy któryś z nich możemy wykorzystać. No pewnie, że możemy, ale skoro pracujemy na wirtualu, no to musimy trochę pokombinować. Drogi mamy dwie. Możemy wykorzystać połączenie poprzez kartę pracującą na wirtualu w trybie NAT. Tutaj potrzebny będzie mechanizm przekierowania portów. Alternatywnie możemy ustawić jedną z dwóch pozostałych kart w tryb pracy karty mostkowanej i przypisać jej adres IP z tej samej puli co fizyczna sieć. My oczywiście pokażemy sobie jedną i drugą możliwość. Najpierw karta NAT. Jak działa sam tryb NAT w VirtualBoxie, no to już wiemy. Jest to ustawienie, które symuluje router.
Kiedy karta maszyny wirtualnej działa w trybie NAT, program VirtualBox staje się dla niej wirtualnym routerem. Dzięki temu, jeśli fizyczny komputer jest podłączony do neta, to również wirtualna maszyna taki dostęp posiada. Analogiczna sytuacja jak fizyczny router i urządzenia w sieci lokalnej? Różnica jest taka, że tutaj sprawę załatwia nam soft. Wyjaśnijmy sobie zatem, czym jest wspomniane przekierowanie portów. Bo aby dostać się z sieci zewnętrznej do serwera, który jest za NAT-em, komputer fizyczny dla naszego ubuńciaka jest przecież w sieci zewnętrznej, to przekierowanie będzie nam potrzebne. Weźmy sobie typowy przykład. W sieci lokalnej pracują cztery komputery z prywatnymi adresami IP. Na jednym z nich postawiony został serwer www, który hostuje jakąś stronę. Do neta urządzenia mają dostęp poprzez router, który po stronie zewnętrznej ma publiczny adres IP.
Na tym routerze działa usługa NAT, czyli translacja adresów sieciowych prywatnych na publiczne i odwrotnie. Dzięki natowaniu. . . urządzenia w sieci lokalnej mogą komunikować się z internetem. Gdyby na ta nie było, no to taka komunikacja nie byłaby możliwa, bo przecież urządzenia mają prywatne adresy, a jak wiemy, po necie śmigamy stosując adresy publiczne. Jak zatem wyświetlić stronę gdzieś na urządzeniu z innej sieci, która hostowana jest tutaj w tej sieci lokalnej, skoro w necie adresy prywatne nie są widoczne? No pewnie część z Was obstawia, że należy w adresie przeglądarki wpisać publiczny adres IP routera. Pomijając oczywiście usługę DNS, jest to słuszna koncepcja. No ale chwila.
Skoro w sieci LAN pracują 4 komputery plus router, który również po stronie LAN-a ma adres prywatny, to skąd wiadomo, że ruch przychodzący z internetu, przychodzący przecież na publiczny adres routera, który żąda wyświetlenia strony, ma być kierowany do konkretnego komputera, który hostuje stronę, a nie do jakiegoś innego. No i tutaj dochodzimy do sedna sprawy, czyli do techniki zwanej przekierowaniem portów. W dużym skrócie, jest to technika, która pozwala wskazać naszemu routerowi do jakiego urządzenia w sieci lokalnej i na jakim porcie ma kierować ruch związany z żądaniami www, które przychodzą z innej sieci, no w tym wypadku z internetu. Po odpowiedniej konfiguracji żądanie, które odbiera router, jest dalej kierowane do serwera, który tą stronę hostuje.
Podsumowując, jeśli żądanie strony www trafi do routera na jego publiczny adres, ten przekieruje ten ruch do właściwego komputera, bo ma w swojej konfiguracji informację, że ten konkretny komputer jest serwerem www. Oczywiście przekierowanie nie dotyczy tylko usługi www. Przekierować porty można tak naprawdę dla każdej usługi, jaka w sieci pracuje, również SSH. Praktycznie każdy nowoczesny router posiada wbudowany mechanizm przekierowania i nie ma wielkiej filozofii w jego konfiguracji. Zobaczmy sobie teraz, jak skonfigurować przekierowanie w VirtualBoxie. Przechodzimy do ustawień sieci, rozwijamy zaawansowane ustawienia dla karty NAT i klikamy w Port Forwarding. Tutaj podajemy nazwę przekierowania. Może być dowolna, ale skoro to połączenie SSH, no to niech będzie SSH. Protokołu warstwy transportowej nie zmieniamy, no bo SSH działa właśnie na protokole TCP. W polu Host IP możemy wpisać adres pętli zwrotnej, czyli 127. 0. 0. 1.
Wówczas tylko z naszego fizycznego komputera będziemy mogli łączyć się z serwerem. Jeśli chcemy, aby można było się z tym serwerem łączyć również z innych komputerów w sieci LAN, no to należy to pole pozostawić puste. Dalej podajemy port, po jakim nasz komputer będzie komunikował się z VirtualBoxem, a dokładniej z wirtualnym routerem, który jest oczywiście w nim zaimplementowany. Można tutaj podać port domyślny dla SSH, czyli 22, ale tylko pod warunkiem, że na naszym fizycznym komputerze nie pracuje już jakiś serwer SSH, który by tego portu używał. Możecie tutaj podać również jakikolwiek inny numer, który jest na Waszym komputerze wolny. Jakie porty w systemie są zajęte, można sprawdzić sobie wydając w terminalu polecenie netstat z parametrem a. Ja ustawię sobie port 22, bo jest mi go łatwiej zapamiętać.
Jeśli Wy podacie tutaj inny, to również musicie go zapamiętać, bo będzie to potrzebne do połączenia. IP gościa pozostawiamy puste. Adres na tej karcie Ubunciak ma z wirtualnego serwera DHCP, który pracuje na VirtualBoxie. tak więc ten będzie wiedział po jakim adresie ma się połączyć. Port gościa to natomiast 22, bo na tym pracuje SSH i tutaj wyjątków już nie ma. Zamykamy okienko i sprawa załatwiona. Do połączeń terminalowych poprzez SSH w Windows 10 można użyć CMD lub też PowerShella, zakładając, że w systemie zainstalowana jest funkcja klienta SSH. Można to sobie sprawdzić wchodząc w ustawienia systemu i dalej aplikacje. Jeśli na liście dodatkowych funkcji będzie klient SSH, no to znaczy, że przez konsolę będzie się można z naszym linuchem łączyć. Do połączeń można zastosować oczywiście zewnętrzne oprogramowanie.
Najpopularniejszym klientem SSH jest oczywiście PuTTY, który możemy sobie za darmo pobrać ze strony projektu. Nie trzeba go nawet instalować, wystarczy uruchomić. Ja zazwyczaj używam właśnie PuTTY'ego do połączeń terminalowych, ale teraz pokażę Wam jak połączyć się poprzez CMD i tego klienta podczas kursu będę używał. Czy klient SSH jest w systemie zainstalowany, można również sprawdzić, wykonując polecenie SSH w terminalu. Jeśli wyświetlają nam się opcje związane z tą komendą, no to znaczy, że klient działa. No to lecimy z próbą połączenia. Polecenie SSH, dalej nazwa użytkownika, którego mamy w Ubuntu, potem małpa, no i dalej adres IP serwera. No tylko jaki? No pewnie ten, który serwer ma przypisany do karty z NAT-em. No to zobaczmy. Jeszcze parametr P, no i numer portu. No i co? No i nic, nie działa. No to zobaczcie teraz.
Zamiast IP interfejsu podam adres pętli zwrotnej. Ha, działa. Połączyliśmy się. Jeszcze hasło, no i można działać. Teraz pewnie u niektórych z Was konsternacja, co się stało. Jak to adres pętli zwrotnej, co to ma być? Zobaczcie tutaj. To jest schemat z siecią lokalną i serwerem www, który wcześniej omówiliśmy. Router ma dwa adresy IP. Publiczny po stronie internetu i prywatny po stronie sieci LAN. Kiedy chcemy z poziomu kompa pracującego w odległej sieci wyświetlić stronę pracującą na serwerze www z sieci lokalnej, no to podajemy przecież nie adres IP tego serwera, ani adres prywatny routera, tylko adres publiczny. Jak dalej żądanie www trafia do serwera, no to już wiemy, bo na routerze działa mechanizm przekierowania portu. Zobaczmy zatem na ten schemat. To jest nasza zwirtualizowana sieć.
Virtual Box jest wirtualnym routerem, który ma adres sieci LAN 10. 0. 2. 2. Po drugiej stronie jest fizyczny komp. który posiada prywatny adres IP, no bo też pracuje w sieci lokalnej, ale dla tego wirtualnego routera jest to adres publiczny. Dlatego przy połączeniu podaliśmy nie adres 10. 0. 2. 15 czy też 10. 0. 2. 2, tylko adres pętli zwrotnej fizycznego komputera. Jeśli komputer łączy się z oprogramowaniem, które jest na nim zainstalowane po sieci, no to zazwyczaj wykorzystywany jest właśnie adres pętli zwrotnej. Gdybyśmy tutaj w opcji przekierowania nie podali adresu pętli zwrotnej, to do połączenia. . . moglibyśmy również użyć adresu IP, jaki posiada komputer, na którym VirtualBox jest zainstalowany. No to teraz opcja numer dwa łączenia się przez SSH z naszym serwerem z wykorzystaniem karty mostkowanej. Tutaj będzie zdecydowanie łatwiej.
Ustawmy sobie po prostu jedną z kart w tryb pracy Bridge. a dalej ustawmy sobie odpowiedni adres IP na serwerze. Skoro jesteśmy połączeni poprzez CMD, no to wykorzystajmy to. Polecenie sudo mcedit, no i dalej ścieżka z ustawieniami sieci. Tutaj mały trik, pojedyncze elementy ścieżki można dopełniać sobie tabulatorem. Jeszcze hasło, no bo plik edytujemy na prawach sudo, no i zmieniamy ustawienia tak, aby ta karta pobierała adres dynamicznie, czyli z serwera DHCP mojej sieci LAN. OK, zapisujemy plik, Stosujemy zmiany w netplanie, no i sprawdzamy jakie IP dostał nasz serwer. To jest słuchajcie ten adres i jego wykorzystamy do połączenia. Do testów użyjemy tym razem innego klienta SSH, który dostępny jest w PowerShellu. Ponownie polecenie SSH z nazwą użytkownika, małpa i tym razem podajemy już adres IP naszego ubuńciaka.
Jeszcze parametr P z numerem portu. Tutaj potwierdzamy, że odcisk palca serwera, czyli ciąg znaków generowanych na podstawie jego klucza publicznego jest nam znany i możemy działać. Ten odcisk słuchajcie jest sprawdzany przy każdym połączeniu. Jeśli łączymy się po raz pierwszy, to klient informuje nas o tym, że nie ma w swojej pamięci cache takiego odcisku. No mieć go nie może, bo to pierwsze połączenie poprzez PowerShell. Poprzez CMD łączyłem się też wcześniej, dlatego monitu nie było. Jak już mówiłem, ten odcisk sprawdzany jest przy każdym połączeniu. Jeśli to kolejne połączenie, a odcisk jest. . . inny niż ten zapisany wcześniej, no to może się okazać, że serwer, do którego się łączymy, nie jest wcale tym, z którym połączyć się chcemy, dlatego należy uważać. Oczywiście to nie zawsze musi być czarny scenariusz.
Odcisk może też się zmienić przy ponownej instalacji serwera SSH albo przy jakimś update'cie, ale zawsze należy być czujnym. Zwróćcie uwagę, że teraz zalogowany jestem do serwera na dwóch wirtualnych terminalach. Na jednym poprzez CMD, a na drugim przez PowerShell'a. Mogę jednocześnie pracować na obu. Kto jest do serwera aktualnie zalogowany? można sprawdzić wydając polecenie WHO. Okej, no to teraz musimy sobie odpowiedzieć na pytanie, której opcji lepiej używać. No to zależy. Jeśli pracujemy w środowisku laboratoryjnym, gdzie będziemy konfigurować usługi tylko do testów i nie chcemy, aby nasze działania na Ubuntu miały jakikolwiek wpływ na pracę fizycznej sieci, no to lepiej używać pierwszej metody, bo ona nie spowoduje ewentualnych zmian w tej sieci. To wynika zwyczajnie z mechaniki działania usługi NAT.
Ruch z sieci prywatnej, z tej sieci, gdzie pracuje Ubuntu, poza SSH oczywiście, nie przechodzi do naszej sieci. Jeśli pracujemy z wykorzystaniem karty mostkowanej, tego trybu Bridge, no to pamiętajcie, że wirtualny serwer widoczny jest w naszej sieci jako host. Jeśli na przykład skonfigurujemy na nim DHCP, a jakiś DHCP już w naszej sieci działa, no to będziemy mieć zdublowane usługi, a to zawsze powoduje problemy. Zatem, jeśli labujemy, testujemy i nie chcemy, aby skonfigurowane usługi działały w naszej faktycznej sieci, no to lepiej wybrać połączenie SSH poprzez tryb NAT. Jeśli natomiast nasz serwer ma udostępniać usługi hostom w fizycznej sieci, no to wówczas można korzystać z trybu Bridge. Oczywiście można też stosować jedną i drugą metodę równolegle.
Ja pracuję w środowisku testowym i nie chcę, aby serwer był widoczny z poziomu mojej sieci, dlatego pozostanę przy połączeniu w trybie NAT. Zmieniam zatem szybko tryb pracy karty Bridge na sieć wewnętrzną i sprawa załatwiona. Uff, dużo tego, a tak naprawdę nie zaczęliśmy jeszcze właściwej pracy z serwerem. Zanim jednak część zasadnicza. . . to pokażę Wam jeszcze jednego klienta SSH. Jest to wielokrotnie wspominany już przeze mnie program Putty. Chyba najpopularniejszy klient SSH ever. Program możecie pobrać sobie z tej stronki, w praktycznie każdym możliwym formacie i na każdą platformę. Co ważne, program jest lekki i jak mówiłem, nie wymaga instalacji. Odpalamy go. Tutaj w tym polu podajemy adres IP naszej maszyny. Domyślnie ustawione jest połączenie SSH, także mamy tutaj już wpisany numer portu. Można sobie konfigurację połączenia zapisać.
i potem tylko ją wywoływać bez konieczności podawania adresu. Łączymy się, no i można działać. Jeszcze jedna ostatnia kwestia na dzisiaj dotycząca SSH. Domyślnie nie ma możliwości logowania się na ruta z wykorzystaniem SSH. Opcja ta ze względów bezpieczeństwa została zablokowana. Jeśli chcecie, można to oczywiście odblokować. Wystarczy edytować plik z ustawieniami serwera SSH, to jest ścieżka do tego pliku, I w sekcji Uwierzytelnianie odhaszować tę linię i tutaj wstawić Yes. Ja już mam to zrobione, bo czasem korzystam z Ruta poprzez SSH, oczywiście tylko w środowisku testowym. Po restarcie usługi logowanie na Ruta będzie już możliwe. No dobra, tyle w temacie SSH. Zajmijmy się teraz samym Ubunciakiem. Jak już mówiłem, pracował dzisiaj będę przez CMD. Na pierwszy ogień weźmy sobie użytkowników, potem zajmiemy się uprawnieniami do plików i folderów.
Na początek wyświetlmy sobie plik z informacjami o userach, wydając polecenie sudo mcedit i dalej ścieżkę do pliku paswd. Ten plik to zbiór wszystkich użytkowników, jakich znajdziemy w systemie. Na samej górze jest root, dalej użytkownicy systemowi związani z konkretnymi usługami, a na dole mamy użytkowników, których utworzyliśmy sobie ostatnio. Po nazwie znajduje się hasło, to znaczy tutaj go nie ma, ale ten X określa, że użytkownik z hasła korzysta. Dalej mamy identyfikator użytkownika oraz grupy. W dalszej części linii mogą znajdować się informacje dodatkowe podawane podczas tworzenia użytkownika, takie jak chociażby imię i nazwisko. Potem jest ścieżka do katalogu domowego, takiego odpowiednika Windowsowego profilu użytkownika, a na koniec mamy jeszcze określony rodzaj powłoki z jakiej korzysta użytkownik. Domyślnie wszyscy korzystają z Basza, my też będziemy. OK, opuszczamy plik.
Teraz dodajmy sobie nowego usera i podajmy tutaj jakieś info o nim. OK. Ponownie otwieramy plik i jak widać wszystko mamy tutaj zapisane. Do tego pliku jeszcze sobie podczas odcinka wrócimy, ale teraz zajmijmy się hasłami. Te, słuchajcie, znajdują się w pliku Shadow, który zapisany jest, jak się pewnie domyślacie, w katalogu ETC. Mamy tutaj zawarte wszystkie informacje dotyczące haseł poszczególnych użytkowników. Same hasła są oczywiście zaszyfrowane za pomocą odpowiednich funkcji i algorytmów. Taki zapis informuje nas, że hasła użytkowników zaszyfrowane zostały za pomocą bezpiecznego algorytmu SHA2, za pomocą funkcji skrótu o długości 512 bitów. Dalej mamy informację, ile dni minęło od zmiany hasła, licząc od 1 stycznia 1970 roku. W naszym przypadku jest to informacja, ile dni minęło od czasu nadania hasła, no bo w międzyczasie go nie zmienialiśmy.
A dlaczego akurat taka data? No jest to słuchajcie tak zwany czas Unixowy. Unix to system operacyjny, który w wielu aspektach jest do Linuxa podobny. A właściwie powinniśmy powiedzieć, że to Linux jest do Unixa podobny. Twórcy Linuxa dawno temu przyświecała myśl, aby stworzyć podobny system do Unixa, bo ten jest o wiele starszy, działający jednak na zasadach wolnego oprogramowania. Datę 1 stycznia 1970 roku wielu fachowców przyjmuje jako początek ery komputerów i dlatego od tej daty liczona jest ilość dni w przypadku ważności haseł. Dalej mamy minimalną ilość dni pomiędzy zmianami, jeśli jest 0 to zmieniać hasła można w dowolnym czasie, potem jest ilość dni określająca ważność hasła, licząc od daty ostatniej zmiany. Jeśli są same dziewiątki, no to hasło nigdy nie wygaśnie.
Na koniec mamy informację ile dni wcześniej przed utratą ważności hasła user zostanie przez system o tym poinformowany. Dalsze pola są puste, bo pewnych ustawień jeszcze nie ma, ale za chwilę zobaczymy jak się to zmieni w zależności od konfiguracji. Ustawienia z tego pliku da się wyświetlić w nieco bardziej strawnej formie, a także modyfikować za pomocą polecenia change. Zanim użyjemy tego polecenia, to pokażmy jak wyświetlać można pomoc dla poszczególnych poleceń i komend w systemie. W Linuxach możemy z pomocy korzystać na dwa sposoby. Pierwszy sposób to wykorzystanie manuali, które zawierają wszystkie i co ważne wyczerpujące informacje dotyczące danego polecenia czy programu. Manuale uruchamia się w systemie bardzo łatwo. Wystarczy wpisać polecenie man i dalej polecenie czy nazwę programu, dla którego manual chcemy wyświetlić. Jak widać, mamy tutaj wszystkie parametry dotyczące interesującego nas programu.
Wszak polecenie to w sumie nic innego jak program. Mamy także nazwy plików, w których zmiany są zapisywane, czy potrzebne uprawnienia do wykonywania poleceń. Poruszanie się po manualu jest banalne. Wystarczy używać klawiszy PageUp oraz PageDown, wówczas przechodzimy pomiędzy całymi stronami. Możemy też używać po prostu strzałek na klawiaturze. Manuala opuszczamy wybierając literę Q na klawiaturze. To jest jedna z opcji dotycząca pomocy dla polecenia. Jest też wersja lżejsza z wykorzystaniem parametru Help. Można też użyć skrótu. Jak widzicie, informacji jest zdecydowanie mniej, nieuruchamiany jest również osobny program, tak jak w przypadku manuali. Help działa dla wszystkich poleceń systemowych i czasami odpala się również, kiedy podamy nieprawidłowy parametr dla jakiegoś polecenia. Ok, wyświetlmy sobie konfigurację hasła dla bolka. sudo change parametr l no i nazwa.
Mamy tutaj podsumowanie ustawień ważności konta oraz hasła, to samo co w pliku passwd, ale jak mówiłem w nieco łatwiejszej do ogarnięcia formie. Pozmieniajmy sobie jakieś ustawienia. Na początek wymóźmy zmianę hasła. Do tego wykorzystamy parametr D z wartością 0. Na koniec polecenia jeszcze nazwa użytkownika, którego zmiana ma dotyczyć. OK. Odpalamy sobie teraz nową konsolę. Kiedy łączymy się poprzez SSH nie ma możliwości zmiany wirtualnego terminala poprzez klawisze funkcyjne. Tutaj za każdym razem musimy uruchamiać nowe połączenie terminalowe. Teraz próba logowania na bolka. No i jest. Jak widać mamy monit o zmianie hasła. Po zmianie ponowne logowanie. No i wszystko działa. Jak widzimy po ponownym odpaleniu ustawień dla Bolka pojawiła nam się tutaj dzisiejsza data. No oczywiście dzisiejsza, czyli ta kiedy nagrywałem wideo.
Ok, ustawmy sobie teraz datę wygaśnięcia konta oraz hasła, a także ilość dni przed wygaśnięciem hasła, kiedy system zacznie informować użytkownika o konieczności zmiany hasła. No to zaczynamy. Oczywiście sudo change, teraz parametr e, który określi nam kiedy konto ma wygasnąć. Po nim data. Można wpisać oczywiście ilość dni, licząc od tej pamiętnej daty, ale może to okazać się nieco kłopotliwe, wszak po drodze mieliśmy kilka lat przystępnych. Tak więc lepiej to zrobić normalnie, czyli w systemie rok, miesiąc, dzień. Teraz parametr duże m oraz ilość dni ważności hasła, licząc od dnia dzisiejszego, no bo dzisiaj hasło było zmienione. Na koniec parametr w. wraz z liczbą, która określa ilość dni pozostałych do wygaśnięcia hasła, od kiedy to system zacznie o tym informować użytkownika. Na koniec nazwa użytkownika i gotowe.
Jak widzicie, parametry w poleceniach można ze sobą łączyć. Teraz ponownie wyświetlamy ustawienia i jak widać wszystko zgodnie z założeniami. Pamiętajcie, że w Linuxach wielkość liter, czy to w parametrach poleceń, czy w nazwach plików ma znaczenie i należy o tym pamiętać. Innym ciekawym parametrem w tym poleceniu jest jeszcze duże I, które określa ilość dni po wygaśnięciu hasła, kiedy to konto zostanie zablokowane. Jeśli hasło zwyczajnie wygaśnie, to user przy logowaniu zostanie poproszony o jego zmianę. Jeśli ustawimy blokadę konta po trzech dniach od daty wygaśnięcia, a bolek w ciągu tych trzech dni się nie zaloguje, jego konto zostanie zablokowane i wówczas jego odblokowanie będzie musiało nastąpić przez administratora. Ustawmy sobie jeszcze ten parametr. No i teraz wyświetlmy sobie plik shadow. Widzimy tutaj, że wszystkie zmiany, jakich dokonaliśmy są zapisane.
To oczywiście nie koniec informacji dotyczących haseł. W Linuxach działa jeszcze jedno polecenie, którym możemy sobie dokonywać pewnych manewrów dotyczących polityki haseł. A jest nim paswd. My tym poleceniem zmienialiśmy, a właściwie nadawaliśmy hasło dla ruta. Ale można dzięki niemu również blokować konta, blokować hasła, również je odblokowywać, czy wyświetlać informacje. Pytanie, a co ze złożonością haseł, minimalną długością, czy stosowaniem wielkich i małych liter w haśle? No oczywiście mamy możliwość konfiguracji tych parametrów, ale tutaj musimy sobie doinstalować pakiet, który to obsługuje, bo domyślnie mamy tylko ustawioną długość na 6 znaków. Ów pakiet to lippam-pw-quality. Po instalacji edytujemy sobie plik commons. passwd, który znajduje się w katalogu pam. d, oczywiście zapisany w katalogu etc. W tej linii możemy sobie dopisać na przykład minimalną ilość znaków. Ustawmy tutaj 8.
Jeśli chcemy, aby w haśle była przynajmniej jedna cyfra, no to dopisujemy tcrEdit równe minus 1. Jeśli chcielibyśmy mieć w haśle przynajmniej jedną małą literę, no to wpiszemy parametr lcrEdit. Duża litera to UCREDIT, a znak specjalny, czyli wykrzyknik czy tam małpa to OCREDIT. Tego wymuszał nie będę, pozostanę tylko przy długości i jednej liczbie. Aby system nie przyjmował haseł niespełniających tych wymagań, bo po takich ustawieniach byłyby tylko monity, a system i tak by je przyjmował, na koniec musimy jeszcze wpisać ENFORCE FOR ROOT. Gdybyśmy tego nie zrobili, to system monitowałby nam tylko, że hasła nie spełniają reguł, ale i tak by je przyjmował. Ten zapis spowoduje. . . że jeśli hasło nie będzie spełniało wymagań, to po prostu nie zostanie zapisane. Sprawdźmy teraz jak to działa.
Tworzymy nowego usera, nadajemy hasło, ja tutaj wpiszę 8 znaków, ale bez cyfry. Jak widać mamy ostrzeżenie, że hasło cyfrę musi zawierać. No to poprawiamy. No i teraz jest OK. Włączenie tego pakietu powoduje również, że zablokowane jest spodawanie haseł, które zawierają następujące po sobie znaki. Zobaczcie, jeśli będę chciał wpisać na przykład hasło QWERTY123, no to nam nie zadziała. Zmuszeni jesteśmy do stosowania złożonych haseł, co jest bardzo dobrym rozwiązaniem. Kwestię haseł mamy dość dogłębnie wyjaśnioną, wróćmy zatem do tematu użytkowników, bo w tej materii mamy jeszcze sobie trochę do pogadania. Wyświetlmy sobie ponownie zawartość pliku passwd, tym razem wykorzystując polecenie getend. Jak widzicie, nie uruchamia się wtedy edytor, a całą zawartość mamy dostępną w konsoli. Zacznijmy od tego, że każdy użytkownik w systemie linuksowym ma swoje unikalne ID. Widzimy to tutaj.
To drugie ID to identyfikator grupy. Podczas tworzenia użytkownika domyślnie tworzona jest również grupa o takim samym ID oraz nazwie odpowiadającej nazwie użytkownika. Informacje o grupach mamy zapisane, jak już wiemy, w pliku GRUB znajdującym się w katalogu ETC. Pytanie, dlaczego numeracja grup i użytkowników, to znaczy te ID zaczynają się od 1000. No ID mniejsze niż 1000 zarezerwowane jest w linuksowych systemach dla użytkowników systemowych. Oprócz użytkowników, nazwijmy to zwyczajnych, takich normalnych, Możemy też również w Linuxie tworzyć sobie użytkowników związanych z tykte z usługami uruchamianymi w systemie i to ich ID jest zawsze mniejsze niż 1000. Ustawienia dotyczące identyfikatorów, a także innych domyślnych ustawień dostępne są w plikach konfiguracyjnych. Jednym z tych plików jest np. adduser. conf. Ustawienia dotyczące identyfikatorów widoczne mamy tutaj. Inny plik z domyślnymi ustawieniami użytkowników to login. devs.
Tutaj również znajdziemy domyślne ustawienia identyfikatorów, ale także haseł. Pytanie, czy zawsze musimy tworzyć użytkowników z domyślnymi ID. No pewnie, że nie musimy. Na etapie tworzenia użytkownika możemy przypisać mu konkretne ID i nie musimy opierać się na domyślnych ustawieniach. Daje nam to raz większą elastyczność, wszak nie musimy decydować się na ID, jakie przydziela system. a dwa jest to bardzo przydatne w kontekście uprawnień do plików i katalogów, które nadawane są nie na nazwy użytkowników, a na ID właśnie. Zobaczmy zatem, jak zindywidualizować sobie proces tworzenia użytkownika. Na początek wyświetlmy sobie pomoc dla polecenia Add User. Co my tutaj mamy? No mamy na przykład parametr, który pozwala nam zmienić ścieżkę do katalogu domowego. Każdy zwyczajny użytkownik w systemie posiada swój katalog na dysku o takiej samej nazwie jak jego login, który domyślnie zapisywany jest w katalogu Home.
Zapis katalogu domowego w home i nazwie użytkownika to oczywiście opcja domyślna. Możemy sobie to zmodyfikować jak nam się podoba. Kolejnym parametrem jest shell. Shell pozwala zdefiniować jaką powłokę przypiszemy dla użytkownika. Jeśli nie zdefiniujemy innej, no to oczywiście domyślnie będzie bash. Inne opcje to identyfikator, informacje o użytkowniku, przynależność do grupy itd. Zobaczmy może jak to działa. Założenie jest takie. Utworzymy sobie użytkownika o nazwie Marian. Katalog domowy damy mu na dysku głównym w katalogu files marian. Co ważne, jeśli taka ścieżka nie będzie istnieć, no to system ją utworzy. Nadajemy teraz unikalne id, no powiedzmy 404. Zapiszmy również informację o imieniu i nazwisku i od razu dołączmy go do grupy sudo. Okej. Oj, tutaj mały błąd, ścieżka musi być bezwzględna. Tak więc tutaj trzeba dopisać slash.
Okej, teraz jest git. Jeszcze hasło. I gotowe. Jeśli na etapie tworzenia usera dołączyliśmy go do określonej grupy, no to wówczas nie będzie tworzona grupa o tej samej nazwie. Zobaczmy, czy user działa. Zalogujmy się w nowym terminalu. No jest. Wyświetlmy sobie przynależność do grupy. Jest sudo, tak więc jest OK. Super, wszystko działa. Nie wiedząc czemu, słuchajcie, podczas przypisywania do grupy na etapie tworzenia usera nie zapisują się zmiany w pliku grab. Zobaczcie. Marian jest w sudersach. to widzimy tutaj, natomiast w pliku grab takiej informacji nie ma. Potwierdzeniem przynależności niech będzie również to, że mogę na Marianie wydać polecenie sudo su. Szczerze to nie mam pojęcia, dlaczego tak się dzieje. Jeśli macie jakieś info na ten temat, napiszcie w komentarzu.
Przy okazji widzimy, że katalog domowy Mariana również został utworzony. Teraz pewnie zastanawiacie się, a co jeśli się pomyliliśmy i chcemy dokonać zmian albo usunąć usera. Jeśli chodzi o usunięcie, no to mamy dwie drogi. Możemy go po prostu zwyczajnie wykasować z pliku passwd. Możemy też użyć polecenia deluser wraz z odpowiednią nazwą. Skoro już zahaczyliśmy o kwestię usuwania użytkowników, to musimy sobie jeszcze wyjaśnić kilka kwestii. Kiedy usuniemy użytkownika za pomocą takiego polecenia bez żadnych parametrów, to musimy pamiętać, że na dysku twardym pozostaje jego katalog domowy. Możemy go oczywiście potem usunąć stosując odpowiednie polecenia, które po prostu kasują katalogi. Jeśli natomiast chcielibyśmy, aby katalog użytkownika kasowany był zawsze przy jego usunięciu, no to możemy zdefiniować sobie odpowiednie ustawienia w pliku o nazwie deluser. conf.
W tym pliku i w tym miejscu możemy sobie ustawić flagę na jedynkę, wówczas usunięcie użytkownika będzie wiązało się również z usunięciem jego katalogu domowego. Możemy tutaj ustawić sobie również opcję kasowania wszystkich plików, których dany user był właścicielem, a także opcję tworzenia kopii zapasowej katalogu domowego. Kiedy tę flagę ustawimy na jedynkę. . . Podczas usuwania użytkownika tworzone będzie archiwum, które zawierać będzie wszystkie pliki z katalogu domowego. Opcja przydatna, jeśli chcemy archiwizować dane użytkowników, których usunęliśmy. Domyślnie archiwum zapisywane jest w katalogu domowym usera, który dokona zniszczenia, to znaczy usunie użytkownika, ale w tym miejscu możemy sobie skonfigurować również inną ścieżkę. Opuszczamy plik bez zapisywania zmian, bo ja modyfikacji tutaj nie chcę. Oczywiście, jak się pewnie domyślacie, można decydować o usunięciu katalogu domowego wszystkich plików i archiwizacji, niekoniecznie na poziomie pliku konfiguracyjnego, ale również na etapie wykonywania polecenia.
Wystarczy wówczas użyć polecenia delusers z odpowiednimi parametrami. Jakie to parametry i jak je stosować, dowiemy się wyświetlając pomoc dla tego polecenia. Jak widzicie, system jest bardzo elastyczny. Większość ustawień można konfigurować sobie globalnie, wówczas zadane operacje wykonywane są już bez konieczności podania parametrów. Można również proces indywidualizować i stosować odpowiednie opcje tylko w konkretnych przypadkach. A co jeśli nie chcemy kasować gościa, tylko zmodyfikować jego ustawienia? No to możemy użyć polecenia modyfikującego ustawienia, a mianowicie User Mode. Za pomocą tego polecenia możemy modyfikować wszystkie ustawienia, począwszy od identyfikatora poprzez przynależność do grup, skończywszy na zmianie ścieżki domowej. Analogicznie do addUser oraz delUser zadziałają polecenia addGrab, oraz DellGrab, odpowiednio tworzące i usuwające grupy użytkowników. Ich działanie pozostawię Wam do samodzielnego przetestowania. W systemach opartych na jądrze Linux istnieje jeszcze inny rodzaj poleceń do tworzenia i usuwania użytkowników. Są nimi UserAdd oraz UserDel.
Są to nieco starsze polecenia, zwane poleceniami niskiego poziomu. Generalnie nie różnią się one od AddUser i DelUser, chociaż niektórzy twierdzą, że nie powinno się ich stosować podczas pracy w terminalu, a tylko w skryptach. bo jak głosi legenda, wówczas mamy pewność, że będą działać na innych dystrybucjach. Ja tego nie potwierdzam, bo nie sprawdzałem i jak dla mnie jest to pewnie tylko kwestia przyzwyczajenia. Temat użytkowników zamykamy i przechodzimy do omówienia zagadnień związanych z uprawnieniami do plików i katalogów. Temat w porównaniu do systemów Windowsowych można powiedzieć łatwy, prosty i przyjemny, bo w odróżnieniu od systemów z Doliny Krzemowej w Linuxach występują tak właściwie tylko trzy uprawnienia. Są nimi odczyt, zapis. . .
oraz wykonanie, a przypisuje się je pojedynczo, grupowo lub też zbiorczo, odpowiednio do właściciela, grupy nadrzędnej, jakiej właściciel jest członkiem oraz pozostałych, czyli wszystkich innych użytkowników systemu. Przy nadawaniu uprawnień stosuje się albo zapis słowny, stanowiący skrót od trzech uprawnień, lub też zapis liczbowy. Zaraz pokażemy sobie jeden i drugi system, a Wy sami zdecydujecie, którego będziecie używać. Zaczniemy od tego, że utworzymy sobie dwóch nowych użytkowników. OK. Po zalogowaniu się na określonego użytkownika znajdujemy się domyślnie w jego katalogu domowym. Ta zasada dotyczy wszystkich kont. W tym terminalu zalogowany jestem na koncie Damian, tak więc w jego katalogu domowym utworzę katalog o nazwie test uprawnień. Teraz polecenie ls z parametrem l i wyświetlamy sobie listę katalogów zapisanych w hołmie Damiana wraz z uprawnieniami. To oczywiście nie jest cała zawartość katalogu domowego, ale tylko utworzone przeze mnie katalogi.
Na razie oczywiście jest tylko jeden. Całą zawartość rzecz jasna da się wyświetlić, ale więcej o poleceniu LS opowiemy sobie następnym razem. Teraz skupmy się na uprawnieniach, a te widoczne są po literce D. D słuchajcie to oznaczenie katalogu, skrót od directory. Dalej natomiast mamy już konkretne uprawnienia. RWX oznacza, że właściciel katalogu czy też pliku, zazwyczaj to użytkownik, który go stworzył, ma pełne do niego prawa. Kolejne RWX oznacza, że grupa nadrzędna, czyli Damian, przy tworzeniu tego użytkownika została również utworzona taka sama grupa. również ma pełne prawa do tego katalogu. Ostatnie trzy pozycje to R, myślnik, X, oznaczające, że pozostali, czyli wszyscy inni użytkownicy systemu, mają prawo do odczytu oraz wykonania, nie mają prawa do zapisu w tym katalogu. Zobaczmy w praktyce, jak to wygląda.
Logujemy się na konto, które przed chwilą utworzyliśmy, przechodzimy do katalogu domowego usera Damian, a dalej do katalogu test uprawnień. Mogliśmy do niego wejść, Spróbujmy teraz utworzyć tutaj jakiś podkatalog. Permission denied. Wszystko się zgadza. Brak możliwości zapisu równa się również brak możliwości tworzenia katalogów. Zmodyfikujmy sobie teraz uprawnienia tak, aby zapis był możliwy dla innych użytkowników. Wracamy do Damiana i do modyfikacji uprawnień wykorzystamy polecenie chmod z odpowiednimi parametrami. Jeśli jesteśmy właścicielem katalogu, nie musimy tych zmian wykonywać na prawach ruta. Możliwości, aby dodać uprawnienia mamy kilka. Najpierw zróbmy tak. chmod o to skrót od others, czyli pozostali, plus w, czyli skrót od write, co oznacza zapis. Na koniec nazwa katalogu. Uprawnienia zmienione. Ponowna próba utworzenia katalogu użytkownikiem u1. Tym razem udana. Jak tłumaczyć taki zapis? Otóż do istniejących już uprawnień.
dodaliśmy uprawnienia zapisu dla pozostałych użytkowników. Jedyne co zrobiliśmy, to dodaliśmy kolejne uprawnienia bez modyfikacji poprzednich. Dodanie oznacza oczywiście plus. Kiedy to samo wykonamy z minusem, odbierzemy prawo zapisu pozostałym użytkownikom. Dodawać i odbierać uprawnienia można oczywiście hurtem. Jeśli chcemy np. odebrać w ogóle prawo do katalogu pozostałym, no to wpiszemy tutaj o minus rx. Jak widać, prawa dla pozostałych całkowicie zdjęte. A kiedy nastąpi próba wejścia do tego katalogu, najpierw go opuśćmy, no to dostaniemy taki komunikat. Przy okazji wyjaśnijmy sobie, co oznacza odczyt i wykonanie w kontekście folderów. No bo jeśli chodzi o pliki, no to prosta sprawa. Prawo do odczytu oznacza możliwość odczytania zawartości pliku, a wykonanie, no to pozwolenie na wykonanie instrukcji, które w tym pliku są zapisane. Przy folderach natomiast odczyt pozwala listować zawartość bez możliwości wejścia do katalogu, a wykonanie.
. . pozwala do niego wejść, ale bez możliwości sprawdzenia zawartości. Zobaczmy. Nadamy teraz prawo odczytu dla pozostałych. I spróbujmy się do katalogu dostać. Znowu mamy zakaz wstępu, ale kiedy już wykonam polecenie ls-l z nazwą tego katalogu, no to mogę zobaczyć co w nim jest. Oczywiście bez szczegółów, ale jednak. Zabierzmy teraz prawo do odczytu, jednocześnie nadając prawo do wykonania. Zobaczmy jaki mamy efekt. Ano efekt jest taki, że mogę do katalogu wejść, czyli można powiedzieć mogę go wykonać, ale co z tego skoro nie mogę odczytać jego zawartości. Taki paradoks. Jeśli chcielibyśmy jednocześnie zabrać prawo dostępu wszystkim użytkownikom łącznie z właścicielem, możemy użyć do tego polecenia z parametrem a-rwx. a oznacza all, czyli wszyscy. Teraz nikt nie ma żadnego prawa do tego katalogu, co widać tutaj.
Analogicznie możemy oczywiście wszystkim przywrócić prawa, wydając to samo polecenie, tym razem z plusem. Gdybyśmy chcieli modyfikować uprawnienia dla właściciela, to użyjemy litery u z odpowiednim symbolem, w zależności od tego czy chcemy nadać czy odebrać uprawnienia. no i odpowiednią literą. Jeśli chodzi o zmianę dla grupy, no to używamy oczywiście litery G. Podsumowując, uprawnienia wykorzystując notację literową nadajemy z plusem i odpowiednimi literami odpowiadającymi uprawnieniom, zabieramy natomiast minusem. Jest to, słuchajcie, bardzo proste, logiczne, nie ma w tym żadnej filozofii. A jak to będzie w notacji liczbowej? No to zobaczmy. Odczyt to 4, zapis to 2, a wykonanie to 1. Suma tych liczb daje nam 7. Tak więc jeśli dla właściciela pliku chcemy nadać pełne uprawnienia, wydajemy polecenie chmod z cyfrą 7. Ale chwila chwila, takiego polecenia wydać nie możemy.
Nigdy nie podajemy siódemki samodzielnie, bo wówczas pełne uprawnienia nadamy pozostałym, gdyż taki zapis wykonywany jest od prawej strony. Gdy to wykonamy, to tylko pozostali użytkownicy bez właściciela i grupy będą mieli prawa do tego katalogu. Jeśli dla właściciela chcemy nadać pełne prawa, no to ponownie siódemkę. Dla grupy odczyt i zapis, no to jest 4 plus 2, czyli 6. Dla pozostałych odczyt i wykonanie, to jest 4 plus 1, a więc 5. Na koniec oczywiście nazwa katalogu. LS minus L i widzimy, że wszystko się zgadza. Pełne uprawnienia dla wszystkich, no to będą 3 siódemki. Jeśli nie chcemy nadawać żadnych uprawnień, na przykład dla pozostałych, no to dajemy 0. Nadając uprawnienia przez notację liczbową, zawsze nadpisujemy poprzednie ustawienia.
Proste, co? W trakcie pracy okaże się oczywiście czy to takie proste, ale tak czy inaczej moi drodzy uprawnienia linuxowe w porównaniu do windowsowych to naprawdę banalna sprawa. To oczywiście nie koniec. Jak powiedziałem wcześniej, zazwyczaj właścicielem pliku jest user, który go utworzył, ale czasem pojawia się potrzeba zmiany właściciela pliku lub katalogu. Do tego wykorzystać możemy polecenie chown z nazwą użytkownika, któremu chcemy własność przydzielić oraz nazwą pliku lub katalogu. Zmieńmy teraz właściciela naszego katalogu i nadajmy własność Marianowi. Poprawka, bo musi tutaj być sudo przy zmianie właściciela. Teraz jest ok. Zmianę własności widać tutaj. Jako, że Marian jest właścicielem, to teraz on ma pełne prawa do tego katalogu. Możemy też oczywiście zmienić sobie własność dla grupy, bo na razie zmiana była tylko dla usera.
To samo polecenie, ale tym razem nazwa grupy z dwukropkiem na początku. Ten dwukropek jest nam potrzebny, ponieważ cała składnia polecenia to user dwukropek grupa, a jeśli zmienialiśmy tylko własność dla grupy, no to pole user pozostaje po prostu puste, a dwukropek zostaje. Moglibyśmy oczywiście jednocześnie zmienić własność dla użytkownika i grupy, wówczas polecenie wyglądałoby tak. Lecimy dalej. Oprócz trzech rodzajów uprawnień, które pokazaliśmy, mamy jeszcze w Linuxach do dyspozycji tzw. bity specjalne. Są nimi tzw. lepki bit, a także user id oraz grab id. Dla zwykłych zjadaczy chleba najistotniejsze jest działanie lepkiego bitu, gdyż on ma bardzo fajne zastosowanie. Załóżmy, że mamy katalog, w którym pliki zapisywane są przez kilku użytkowników. Aby w tym katalogu mogli tworzyć zasoby, muszą mieć przydzielone prawa zapisu do tego katalogu, no bo inaczej nie będą tego mogli zrobić.
To jednak niesie ze sobą pewne zagrożenie. Otóż jeśli mają zapis, no to niestety mogą też usuwać zawartość, nawet jeśli nie są właścicielami. Tak działają uprawnienia w Linuxie. Lepki bit działa tak, że zabrania usuwania zasobów, których nie jesteśmy właścicielem. Tak więc poszczególni użytkownicy nie mogą sobie wzajemnie usuwać plików. Zobaczmy jak to działa. Utwórzmy sobie katalog o nazwie pliki i nadajmy mu pełne prawa. Teraz dopiszmy do tego katalogu lepki bit. Możemy to zrobić na przykład wpisując A plus T. Można to zrobić również tak. Jedynka i trzy siódemki. Wówczas za jednym razem nadajemy pełne uprawnienia, a także dodajemy lepki bit. Ta jedynka to jest właśnie lepki bit. Uprawnienia wówczas wyglądają tak, że na końcu mamy literkę T. No to testujemy.
Utwórzmy nowy katalog w folderze pliki za pomocą pierwszego usera. OK. A teraz drugim userem sprawdźmy, czy będziemy mogli ten katalog usunąć. No nie da się. Otrzymujemy komunikat, który odmawia tej operacji. Tak właśnie działa lepki bit. Innym specjalnym rodzajem bitu jest, jak ja to nazywam, bit G. G rozumiany jako grupa. Działa on tak, że nadaje identyfikator grupy właściciela katalogu wszystkim nowo utworzonym katalogom, bez względu na to, kto je utworzył. Teraz dodajmy bit specjalny G. Można to zrobić takim zapisem. Można to zrobić również za jednym zamachem, wydając takie polecenie. A ta dwójka oznacza bit specjalny G. Teraz LS minus L. No i widzimy, że execute dla grupy zmienił się na S, a to oznacza, że dodano bit specjalny dla grupy.
No to teraz utwórzmy sobie zasób w tym katalogu innym użytkownikiem. Jak widać, pomimo tego, że ten user do grupy Damian nie należy, dla katalogu został nadany identyfikator właśnie grupy Damian. Jeśli chcemy, aby osoby pracujące na tym katalogu miały takie same uprawnienia do niego jak określona grupa, no to wówczas ustawiamy bit specjalny i sprawa będzie załatwiona. Jeśli chodzi o pliki z ustawionym takim bitem, to zadziała to tak, że jeśli będziemy go wykonywać, no to wykonanie nastąpi na prawach grupy, która go utworzyła, a nie na prawach wykonującego. Podobnie działa jeszcze ostatni bit specjalny o nazwie UID, czyli po prostu skrót od user. Kiedy nadamy taki bit dla pliku, można to zrobić na przykład takim poleceniem, no to wówczas user, który go wykonuje, wykona go na prawach właściciela, a nie na swoich.
Mechanizm bitów specjalnych GID oraz UID należy stosować z rozwagą. bo jeśli zostaną użyte w sposób nieprzemyślany, nieprawidłowy, no to może się zdarzyć, że niewłaściwi użytkownicy będą mieli pełne prawa do jakichś zasobów, a nie zawsze tego chcemy. Omawiając tematykę uprawnień, nie sposób nie wspomnieć o mechanizmie ich dziedziczenia. W przeciwieństwie do Windowsa, w Linuxach domyślnie zjawisko dziedziczenia uprawnień nie występuje. To znaczy pliki i katalogi, które tworzone są w zasobie z określonymi uprawnieniami, takich samych uprawnień nie będą mieć. Każdy plik i katalog Tworzony w katalogu domowym użytkownika ma uprawnienia domyślne 775 dla katalogów oraz 655 dla plików. W przypadku katalogu domowego RUT-a, a także katalogu głównego, uprawnienia te ustawiane są na 755 dla katalogów oraz 644 dla plików. Jeśli chcemy, aby nowo utworzone zasoby w danym katalogu miały inne uprawnienia, no to możemy zastosować mechanizm zwany UMASK.
UMASK definiuje domyślne uprawnienia dla zasobów tworzonych w danym katalogu. Zobaczmy jak to działa. Widać tutaj domyślną maskę. Dlaczego są zera i dwójka nieuprawnienia, o których mówiłem? W przypadku UMASK mamy do czynienia z odwrotnością liczb określających uprawnienia. Dwójka oznacza, że od pełnych uprawnień odejmujemy dwa, co daje nam piątkę, a to oznacza, że użytkownicy nie będący właścicielem pliku i katalogu oraz nienależący do grupy mają uprawnienia tylko do odczytu i wykonania. Drugi bit, czyli pierwsze zero od prawej strony oznacza, że grupa ma pełne uprawnienia no bo od 7 odjęto 0, co daje 7. Analogicznie kolejne 0. W przypadku plików uprawnienia domyślne są jak mówiłem na poziomie 6. 6. 5 i tak faktycznie jak widzicie jest. Domyślnie systemy linuxowe nie dają prawa execute przy tworzeniu pliku pomimo odpowiednio ustawionej maski.
Maskę oczywiście można zmodyfikować, wydając polecenie umask z parametrami. Zrobimy tak, że nowo utworzone katalogi tutaj będą miały pełne prawa. Maskę zatem ustawiamy na 3. 0. Tworzymy nowy katalog. I jak widać jest jak mówiłem. Nowy katalog ma pełne uprawnienia. Tutaj dziedziczenie będzie działać, to znaczy jeśli w katalogu, który stworzyłem utworzę kolejne, to również one będą miały pełne uprawnienia, ale tylko kiedy ten użytkownik, na którym u mask ustawiliśmy będzie je tworzył, bo co ważne maska nie jest ustawieniem dla innych użytkowników. To znaczy, że kiedy w tym katalogu będzie pracował inny użytkownik, to dla niego maska nie będzie taka jak ustawiłem, tylko domyślna. Zobaczcie, inny user, ten sam katalog. Tworzę w nim zasób i jak widzicie nie ma on pełnych uprawnień, tylko domyślne.
To, że ustawiona maska działa tylko na użytkowniku, który to wykonał, to jest jedna rzecz. Działa to też tylko podczas aktywnej sesji. To znaczy, jeśli dany użytkownik się przeloguje, to wówczas maska powróci do domyślnych ustawień. O tym należy pamiętać. Pojawia się teraz pytanie, czy da się zrobić tak, aby zawsze nowo tworzone zasoby w jakimś katalogu miały te same prawa dla wszystkich użytkowników? No pewnie, że się da. Jest to możliwe i co ważne bardzo często używane. CHMOD to dość stary system nadawania uprawnień. Jak widzicie nieco mało elastyczny i przy bardziej zaawansowanych ustawieniach czy zadaniach nie sprawdzający się zbyt dobrze. Na szczęście istnieje również bardziej rozbudowany system uprawnień oparty na listach kontroli dostępu do plików i katalogów.
Biorąc pod uwagę fakt, iż odcinek jest już bardzo długi i że tak naprawdę my jesteśmy dopiero na początku linuxowej drogi, nie będę Was zbyt długo zanudzał istotą działania programu zwanego setfacl, bo to tym poleceniem konfigurujemy wspomniane ACLki. Pokażę natomiast w jaki sposób spowodować, aby zawsze dla wszystkich użytkowników ustawić określone prawa do plików i katalogów. Zrobimy to sobie na nowo utworzonym katalogu. Nazwę go ACL test. Wcześniej wydałem polecenie UMASK w tej lokalizacji dla tego użytkownika. Dlatego ten nowo utworzony katalog ma pełne prawa. Teraz polecenie setfacl. Parametr duże R oznaczający rekursywność. Dzięki temu ustawienia zastosowane będą do wszystkich plików i podkatalogów. Dalej parametr małe d oraz małe m. Te parametry modyfikują aktualne ustawienia. Dalej u oznaczające użytkowników. Po dwu kropku możemy wpisać nazwy tych użytkowników, ale my tutaj zostawimy to pole puste.
Dzięki temu ustawienia będą dotyczyły wszystkich. Po dwu kropku prawa do odczytu. zapisu i wykonania, a dalej już nazwa katalogu lub też ścieżka do niego. Gotowe. Sprawdźmy. Tworzymy zasób innym userem, teraz ls-l i jak widać uprawnienia są zachowane. Przechodzimy do tego katalogu i tworzymy nowy. Ponownie ls-l i jak widać dziedziczenie również działa. Uff, długi ten odcinek, chyba jeden z najdłuższych jakie przygotowywałem, ale jak widzicie Linux jest jak misje w trzecim Wiedźminie. Zaczynamy jeden wątek, a za chwilę misja rozciąga się na 50 innych. Tutaj jest dokładnie tak samo. Trzy wydawałoby się proste tematy, a ile tłumaczenia, ustawień i poleceń. I na koniec jeszcze jedna bardzo ważna kwestia. Uprawnienia w Linuxach, jak już wspominałem na początku, nadawane są na ID, a nie na nazwę użytkownika.
Co to oznacza? No oznacza to tyle, że jeśli user. . . dostanie od nas jakieś uprawnienia, to one zostaną przydzielone nie na jego nazwę, a na ID. Kiedy go usuniemy, to ID się zwolni i może zostać przypisane do kolejnego użytkownika, którego utworzymy. Wówczas ten nowy użytkownik będzie miał takie same prawa jak ten usunięty user, czego wcale możemy nie chcieć. Uważajcie na to, zawsze nadawajcie unikatowe identyfikatory i zwracajcie uwagę na uprawnienia. Okej, na tym zakończmy dzisiejsze spotkanie. W kolejnym odcinku zajmiemy się pracą na plikach i katalogach, a także omówimy sobie polecenia, których również dzisiaj używaliśmy, a których z uwagi na długość odcinka nie komentowałem. Popracujemy sobie również też trochę nad archiwizacją danych. Wszystkie użyte dzisiaj polecenia standardowo publikujemy dla Was na stronie pasji. Na teraz to tyle. Zapraszamy do kolejnych produkcji. Pozdro!.
S K R Y B O T
Skrybot. 2023, Video transcriptions from YouTube
By visiting or using our website, you agree that our website or the websites of our partners may use cookies to store information for the purpose of delivering better, faster, and more secure services, as well as for marketing purposes.