Ze względów bezpieczeństwa dostęp do systemu jakim jest system Linux jest ściśle ograniczony, co widoczne jest między innymi monitem logowania czy podania nazwy i hasła po załączeniu systemu i przygotowania go do działania. Teoretycznie nic więcej się nie da zrobić (Teoretycznie, gdyż mając fizyczny dostęp do urządzenia można wykonać wiele, obchodząc monit logowania).

Skąd się wzięła idea tak rygorystycznego zachowania się wobec użytkownika? Wynika ona z faktu, gdyż jedynie największym szkodnikiem dla systemu jest sam jego użytkownik. Niegdyś, gdy sam komputer służył głównie do wykonana wymagane zadania, dostęp do niego miały wyszczególnione osoby, które po prostu wiedziały jak dane zadanie obsłużyć (mowa o dawnych systemach wsadowych). Obecnie ze względu na popularność, dostęp do komputer jest wszechstronny i każdy może z tej technologii korzystać. Zaczynają się problemy z poufnością danych etc. Ale nie tylko to stało się powodem do tego by system działa w danym kontekście zalogowane użytkownika. Umożliwia to także zarządzeniem dostęp do sprzętu, innych zasobów jakimi dysponuje system, procesami, pamięcią, samym procesorem etc. Wszystkie te operacje, jakie muszą być reglamentowane wobec użytkownika w sposób selektywny. itd.

Jak widoczny jest user w systemie Linux? Ano rozpoznaje się go po tzw numerze UID. Fakt zastosowania numerowania usera wynika z łatwość porównywania praw dostęp do pliku. Gdzie plikiem stanowi (w systemie Linux) wszystko (łącznie z klawiaturą etc, są wyszczególnione urządzenia wejścia-wyjścia w katalogu /dev/)

Gdyby szło porównywać ciągi znaków (każdy plik ma swojego owner'a) z nazwą usera aktualnie zalogowanego, porównanie to trwało by dłużej, a ilość takich porównań jest ogromna w trakcie działania sesji zalogowania usera do systemu. Z tego też posługuje się numerami UID. Oczywiście w celach ułatwienia autentykacji osoby do systemu, stosuje się nazwy usera, czyli login name.

W przypadku systemu Linux, te dane są przechowywane w odpowiednich plikach: - /etc/passwd - /etc/shadow - /etc/group - /etc/gshadow Gdzie dwa ostatnie dotyczą grup zdefiniowanych w systemie Linux.

/etc/passwd

Plik ten zawiera powiedzmy bazę userów danego systemu (co nie oznacza, że każdy z nich może się zalogować, niektórzy z nich istnieją, w celach rozdzielenia praw dostępu do poszczególnych zasobów, tego typu mechanizm zabezpiecza przed sytuacją, gdzie to w tym samym kontekście, możliwy jest dostęp do dysku i audio). Każdy kolejny wiersz definiuje każdego usera (oczywiście poprawnie zapisany wiersz).

Schemat takie wpisu ma postać: [login name]:[hasło]:[UID]:[GID]:[dane identyfikacyjne]:[home]:[shell]

Jak widać, na pierwszym miejscu stoi nazwa usera, czyli login name. Jego długość w zależności od systemu, od 8 znaków do 32, gdzie znakami mogą być: cyfry, litery, szczególne znaki specjalne (np. dwukropek nie może być, gdyż stanowi on separator wiersza w pliku). W odróżnieniu od systemu Windows, domyślnie polityka systemów uniksopodobnych rozróżnia się mniejsze i większe litery (gdyż posiadają one inny numer w tablicy kodowej, więc są one inne).

Druga kolumna, to miejsce na hasło. Obecnie, miejsce to jest miejscem pustym, zawiera tylko informację o tym czy hasło jest ustawione. Obecność znaku 'x' oznacza obecne hasło. Ze względów bezpieczeństwa to hasło znajduje się w pliku innym, do którego dostęp ma tylko i wyłącznie admin systemu (nazywany root'em). Brak znaku 'x' postrzegane jest przez system jako brak ustawione hasła (niegdyś tak było, pomimo tego że obecne było hasło w postaci zaszyfrowanej w pliku przechowującym hasła).

Trzecia kolumna, to kolumna gdzie znajduje się nie powtarzalny numer UID dla każdego user'a. Jest on przypisany do każdego user'a. W momencie autoryzacji i uznania tożsamości osoby logującej, przypisuje się ten numer do danej sesji. Od tego momentu, osoba ta jest postrzegana w tym systemie po tymże numerze UID, i na podstawie tego numeru decyduje się o prawach dostęp.

Czwarta kolumna to kolumna zawierająca GID. Jest to numer grupy podstawowej danego usera wpisanego w system. Osoba mająca przypisana numer grupy podstawowej teoretyczni jest jej właścicielem, ale nie do końca tak jest. Np. w sytuacji jaką jest grupa studentów, każdy z nich ma ten numer ustawiony, jako numer grupy podstawowej, ale kto inny jest jej właścicielem. Gdzie taka informacja może być?! Przy tworzeniu nowego usera, system mając ustawione domyślnie tworzenie usera wraz z jego grupą podstawową, tworzy grupę o takiej samej nazwie.

Piąta kolumna to dane dotyczącego tegoż usera. Zarządzanie tymi danymi odbywa się przy pomocy aplikacji zewnętrznych, jak np. finger, gdzie komendą chfn uruchomioną w danym kontekście, można zmienić zawartość tejże kolumny. W przypadku finger'a zawartość tej kolumny podzielona jest na 4 podkolumny, oddzielone przecinkiem.

Szósta kolumna, to kolumna zawierająca bezwzględną ścieżkę dostępu do katalogu domowego. Najczęściej, dla osoby fizycznej, jest on w katalogu /home/login_name, ale w przypadkach, gdzie jest to jakiś user, będący daemonem, jest to katalog, znajdujący się w katalogach takich, jak /var/lib/ czy inne wyszczególnione w systemie.

Siódma kolumna zawiera bezwzględną ścieżkę do powłoki, jaka ma zostać uruchomiona po zalogowaniu się do systemu (czyli poprawnej autoryzacji user'a). Musi ona być uznana przez system w pliku /etc/shells

Plik gdzie są hasła, jest to plik o ścieżce /etc/shadow

Dostęp do tego pliku, ma tylko i wyłącznie root, czyli odczyt (jak w przypadku pliku /etc/passwd) dla zwykłego usera, nie jest możliwy. Jest to jedna z form zabezpieczenia danych odnośnie głównej kwestii systemu (ograniczania dostępu do niego).

Plik ten podobnie, jak plik /etc/passwd zawiera strukturę wierszową, i każdy kolejny wiersz posiada informacje o haśle odnoszącego się do każdego z user'ów. Każdy wpis podzielony jest na 9 kolumn, oddzielnych dwukropkami. Schemat jest następujący:

[login]:[hasło shadow'owane]:[kiedy ustawione]:[minimalny wiek hasła]:[maksymalny wiek hasła]:[termin ostrzeżenia]:[blokada po przekroczeniu czasu]:[wygaśnięcie]:[inne]

Login to podobna nazwa, jak w przypadku pliku /etc/passwd. Obecność podobnych nazw, skutkuje wykorzystaniem informacji dotyczących hasła, przypisanych do danego user'a.

Hasło - postać shadow'owana, czyli potocznie mówione, znaczy zaszyfrowana. Postać jaką przyjmuje to pole, ma następującą formę:

$[kod dekryptera]$[sól]$[postać zaszyfrowna]

Teoretycznie, dostęp do tego pliku ma tylko root, z więc z tego względu, podejrzenie, nawet zaszyfrowanej postaci hasła ma tylko root, co raczej mu nie jest potrzebne, z racji tytułu admina systemu, i możliwości zmiany kontekstu na jakikolwiek inny, bez podawania hasła. Niegdyś hasło to znajdowało się w pliku /etc/passwd będący plikiem o uprawnieniach 644, czyli rw-r--r--, gdzie możliwy był odczyt przez każdego. Na chwilę obecną, plik przechowujący hasła, ma uprawnienia 600, czyli tylko i wyłącznie root może go odczytać i zapisać coś do niego (Nie sądzę raczej, by były jakiekolwiek uprawnienia dla grupy, w tym wypadku root, gdyż poza root'em nikt do niej nie należy)

Są także inne formy zabezpieczenia dostępu do danych o hasłach, mianowicie, umieszczenie go w innym katalogu, do którego także dostęp ma tylko root (700). Tego typu zabieg umożliwia dwukrotne zabezpieczenie dostępu do pliku, bo i do katalogu, i do pliku dostęp ma tylko i wyłącznie root, poprzez ustawione atrybuty dostępu i bycie ich właścicielem.

Dodatkowo: w miejscu, gdzie jest cała ta śpiewka o haśle mogą się pojawić inne znaki, jak np: - ! czy !! - hasło nie ustawione - * - hasło nie poprawne

Kolejne kolumny dotyczą kwestia związanej z czasem odnoszącym się do hasła. Poszczególni userzy mogą mieć odmienną politykę hasła, tj inaczej ta ich prywatna informacja, jaką jest hasło, jest traktowana. Chodzi głównie tutaj o wymuszanie na userze zmianę tego hasła. Najbardziej liebarlny przypadkiem jest sytuacja, gdy to nie wymusza się na userze zmiany tegoż hasła. Raczej powinno być tak tam, gdzie ta dana stacja nie stawi zbytniej wartości, lub też dostęp do niej jest ściśle ograniczony. Jednakże w sytuacji, gdzie z danej maszyny (dajmy na to serwera) korzysta więcej osób, istnieje prawdopodobieństwo, że zostanie do tej maszyny złamany dostęp, bo ktoś z tej setki userów ma wystarczające proste hasło, by je złamać nawet samym myśleniem. Tego typu potencjalne zagrożenie włamania się na serwer musi zostać w jakiś sposób zminimalizowane. Jedną z form uniknięcia złamania hasła, jest jego regularna zmiana (na inne za każdym razem) Ku temu stosuje się odpowiednio: - ograniczenia czasowe odnośnie hasła - odpowiednia długość hasła - historia haseł - słownik (by to hasło, nie było słowem, a jakąś kombinacją) oraz inne wymyślne metody, by hasło było trudne (kombinacja dużych małych liter, znaki specjalne, cyfry etc. im więcej możliwych robaczków, tym więcej wariacji danego hasła)

Ograniczeni czasowe zdefiniowane są w pliku przechowującym owe postacie zaszyfrowane haseł, i jest to w kolumnach za hasłem. Pierwsza z nich, czyli trzecia od początku, to miejsce gdzie podaje się kiedy to hasło zostało zmienione względem dnia będącego początkiem ery Unix'a, czyli 1 styczeń 1970r. Podana jest ilość dni względem tejże daty.

Kolejna kolumna czyli czwarta ma ilość dni względną, względem daty zmiany hasła, określające ile dni po zmianie hasła, może nastąpić jego kolejna zmiana, czyli tzw minimalny wiek hasła. Nie dla każdego usera musi być taka sama ilość dni. Nie definiuje się tego globalnie (przynajmniej nie dla istniejących userów, przy dodawania nowego usera ustala się te poszczególne ograniczenia czasowe, jeśli nie ma ich podanych, to bierze się domyślne, z pliku /etc/default/adduser czy jakoś tak). Minimalny wiek hasła zapobiega sytuacji, w której dana osoba zmienia hasło, i kolejno dokonuje n zmian pod rząd, by wyrzucić z listy historii haseł swoje ulubione, i ustawić je ponownie.

Piąta kolumna zawiera informacje odnośnie wieku życia tego hasła, czyli na ile dni od momentu ustawienia hasła, dane hasło jest ustawione. Przed upływem tego okresu teoretycznie należy je zmienić, o czym zacznie nas informować system w odpowiedni sposób na ileś dni przed upływem ważności hasła. Inaczej nazywany maksymalnym wiekiem hasła.

Szósta kolumna to kolumna zawierająca na ile dni przed upływem maksymalnego wieku hasła, zaczyna się pojawić odpowiednia informacja dla danego usera, gdy się loguje do systemu. Ta informacja ma charakter tylko teoretyczny. Czy hasło zostanie zmienione, czy nie, zależy od usera.

Siódma kolumna zawiera informacje odnośnie, na ile dni po upływie ważności hasła, konto jest blokowane. Jak widać, można nie zmienić, gdyż zawsze jakiś czas po upływie ważności hasła istnieje, chyba że ustawione jest na zero. Blokada konta skutkuje tym, że zmiana hasła wymagana do odblokowania, możliwa jest tylko i wyłącznie przez root'a systemu. Lepiej do tego nie dopuścić.

Ósma kolumna zawiera informację odnośnie tego, kiedy konto traci ważność (inactive) Pomocne przy zakładaniu kont tymczasowych, gdzie admina nie interesuje nic poza założeniem tego konta. Kolumna ta zawiera ilość dni od daty UNIX, kiedy to konto jest całkowicie wyłączane z możliwość korzystania z niego. Nie oznacza to, że dane danego usera są usuwane. etc. Jedynie dostęp do nich będzie nie możliwy przez konto które ma wyłączoną opcję logowania się do systemu.

Dziewiąta kolumna, pod dwukropku jest zarezerwowana do innych celów. Ogólnie nic tam nie. A co może być - nie wiadomo.

Z grubsza, informacje odnośnie danego usera trzymane są w dwóch plikach (nie biorąc pod uwagę innych, jak grupy etc) gdzie w pliku /etc/passwd są dane dot. konta (login, UID, GID, info, shell, home), a w /etc/shadow dane odnośnie hasła (hasło, kiedy, min, max, przed, blokada, wygaśniecie).

Grupy

Zaś gdzie są definiowane grupy systemu? Jak wiadomo, system Linux korzysta z tego, że cała jego struktura jest określona na plikach (łącznie z urządzeniami etc.) do których dostęp musi być reglamentowany. Odbywa się to poprzez istnienie tzw atrybutów każdego pliku, określonych w inode'zie. Jak na razie wiadome nam jest o istnieniu usera w systemie oraz innych userów. Czyli teoretycznie dostęp do pliku można podzielić na jego onwera i reszte. Oczywiście skądś istnienie grupy się musiało się pojawić. Mianowicie, niejednokrotnie pojawiała się sytuacja, gdzie wymagany był dostęp do danego pliku przez kilka osób, a każda z tych osób ma swoje własne konto. Jak zrobić, by równocześnie dostęp na tych samych zasadach miało kilka osób różnych UID'ach. Umieszczanie tego typu informacji w inode'dzie mogło by być rozwiązaniem, be precyzuje się dokładnie kto może, a kto nie. Ale gdy chodzi tutaj o pliki reprezentujące urządzenia, jak audio czy video (np dostęp do framebuffer'a) dla x-naście osób skutkowało by to dopisaniem x-UID'ów do inode'a. Wtedy taki inode by dużo zajmował, a samo sprawdzenie, czy mam dostęp do tego pliku trwał by długo w zależności od ilość userów korzystających z tego pliku itd.

Jeszcze inny sposób na udzielenie dostępu do pliku, czy współdzielenie tego pliku przez kilka osób istnieje. Mianowicie: można dublować nazwy userów. Tzn każdy z nich ma ten sam UID, a loguje się przy pomocy swojego hasła, gdyż rozróżniamy ich w plikach /etc/passwd i /etc/shadow Mamy przecież dwa różne wpisy, chociaż ten samu UID.

Stąd też i grupa. Logują się do systemu, po poprawnie zapodanym haśle, poruszam się po drzewie katalogów, mając przypisany UID do mojej sesji oraz masę GID'ów (czyli grupowych identyfikatorów) do grup których ja należę (oczywiście z wyróżnieniem mojej grupy podstawowej). I tak mogę należeć do grupy apache,mysql,audio,mpd..., czyli mogę na plikach danej grupy działać, zgodnie z przypisanymi im atrybutami dla danej grupy. Ułatwia to znacznie zarządzanie, o ile nie zaczyna się z bardzo wyszczególnionymi zastrzeżeniami co do dostępu do pliku.

Plik, gdzie przechowuje się tego typu informacje, to plik /etc/group. Jego postać jest oparta na podobnej do dwóch poprzednich plików, tj. /etc/passwd i /etc/shadow. Czyli mamy do czynienia z kolejnymi wpisami, które definiują istnienie kolejnych grup w systemie. Na pewno na tej liście znajdują się grupy podstawowe userów, czyli grupa root i poszczególnych userów w systemie. Są także grupy poszczególnych userów, jacy istnieją dla właściwego zarządzania dostępem do plików (zasobów etc.) czyli bin dev apache mysql... takie grupy także mogą istnieć.

Schemat podziału wiersza:

[group name]:[hasło]:[GID]:[lista członków grupy]

Pierwsza kolumna, to kolumna definiująca nazwę grupy. Musi być unikatowa w obrębie systemu. Dla grup podstawowych danych fizycznych userów, ich nazwy są identyczne z nazwą loginów poszczególnych userów (tzn. domyślnie polityka dodawania nowego usera sprowadza się także do utworzenia jego grupy podstawowej o tej samej nazwie co user, chyba, że już takowa istnieje w systemie, oraz jeśli nie zostało zaznaczone inaczej w konfiguracji, czy opcjach dodawania nowego user'a).

Drugie pole, to pole, które zawiera informację (kiedyś zawierała) o zaszyfrowanej postaci hasła. Obecnie jest tylko 'x' co oznacza (oznaczało niegdyś) istnienie hasła, lub jego brak (że teoretycznie tego hasła nie ma). Tak czy inaczej hasło zostało podobnie jak przy /etc/passwd przeniesione do innego pliku, tym razem do /etc/gshadow.

Trzecie pole, to pole zawierające numer grupy, czyli tzw. GID. Jest on unikatowy w obrębie systemu.

Czwarte zaś zawiera listę userów, którzy przynależą do danej grupy. Oczywiście, może się tak zdarzyć, że jej właściciel jest do niej przypisany. Z racji bycia właścicielem danej grupy, dany user, nie musi się znajdować na tej liście. Za to, jeśli dana grupa, stanowi czyjąś grupę dodatkowo, musi się znaleźć jego login na tej liście.

Dane odnośnie hasła do danej grupy znajdują się w pliku /etc/gshadow. Oczywiście, pytanie po co hasło, jak logując się na swoje konto, jesteśmy jednocześnie w danej sesji przypisani do jakiś grup. Nie do końca tak musi być. Podobnie jak możemy się przelogować (inaczej zmienić kontekst w obrębie użytkownika), to także możemy się przelogować na inną grupę (inaczej zmienić kontekst w obrębie grupy) i służy do tego komenda sg gdzie jako argument podajemy nazwę grupy. Przełączenie kontekstu w obrębie grupy, nie zmienia naszego kontekstu user'a, ale umożliwia administrowanie daną grupą inną niż nam była przypisana jako grupa podstawowa oraz poruszanie się po katalogu plików jakby będąc przedstawicielem tejże grupy. BTW zmiana kontekstu w obrębie usera, odbywa się poprzez komendu su Przy każdej zmianie kontekstu uruchamiana jest kolejna powłoka interaktywna (jako podproces procesu macierzystego danej powłoki). Tak dzieje się i przy su i przy sg.

Nie było jeszcze powiedziane nic o tym, czym różni się grupa podstawowa, której jesteśmy właścicielem, od grupy podstawowej której właścicielem nie jesteśmy lub innej grupy, do której jesteśmy przypisani. A mianowicie, będąc właścicielem grupy podstawowej możemy nią zarządzać, czyli dodawać nowego user, wykluczać usera z grupy itd. Ułatwia to przeciętnemu użytkownikowi zarządzaniem własnymi zasobami, jakimi są jego własne pliki oraz katalogi, którymi dysponuje. Natomiast, jeśli nasz grupa podstawowa, nie jest naszą grupą, czyli nie jestem jej właścicielem, to nie mam takich możliwości administracji.

Schemat takiej jednej linijki zawierającej hasło grupowe, czyli w pliku /etc/gshadow:

[group name]:[hasło shadow'owane]:[lista adminów]:[lista członków]

I tutaj na pierwszy rzut oka pojawia się pewna nieścisłość odnośnie powyższego wywodu, gdyż może być kilku adminów danej grupy, którzy są z definicji grupy jej właścicielami, mimo że nie musi to być ich grupa podstawowa.

Nazwa grupy jest taka sama jak w przypadku pliku /etc/group. Jeśli chodzi o hasło, to jest to hasło szyfrowane podobnie jak w przypadku haseł w pliku /etc/shadow. Postać tego pola jest podobna, łącznie z wyjątkami, jakimi są nieustawione hasło, czy nie poprawne.

Lista adminów, czyli tych userów (zdefiniowanych w /etc/passwd po ich loginie, co którzy mogą zarządzać grupą, czyli dodawać nowych userów do grupy itd.

Lista członków, jak gdzieś tam powyżej.

Dodatkowo istnieje jeszcze szereg innych ewentualności odnośnie zarządzania kontami danych userów w systemi Linux. Przy dodawani nowego usera, jeśli nie są podane, wykorzystuje sie opcję defaultowe, zdefiniowane w plikach defaultowych gdzieś w /etc/ a dokładnie, np. przy dodawaniu user, plik konfiguracyjny (dla Debian) to /etc/adduser.conf dla deluser, to /etc/deluser.conf itd. gdzie w tych plikach obecne są informacje odnośnie opcji jakie powinny być dodane do wywołanej w powłoce poleceniu.

Istnieje także szereg rozwiązań komercyjnych, odnośnie samego systemu autentykacji, jak na przykład przechowywanie danych o userze w pliku /etc/security/user w postaci poszczególnych recordów, gdzie definiuje się dane wymagane atrybuty danego usera, zaś nie zdefiniowane, są takie same jak domyślne, które także można nadpisywać.

Stosowane komendy do administracji kontami w systemie Linux: