Otoczenie sieciowe - Sieć SMB utworzono: 27/07/2003 :: modyfikacja: 01/05/2008 autor: Marcin Moczkowski :: glappo (at) banita (dot) pl Użytkownicy i uprawnienia - Samba/Unix Każdy system Unix zgodny ze standardem POSIX posiada obsługę użytkowników i grup. Udostępniając jakiś zasób należy pamiętać zarówno o uprawnieniach danego zasobu zdefiniowanych w Sambie jak i uprawnieniach danego systemu plików. Warto też zdawać sobie sprawę co danemu użytkownikowi "wolno" a czego nie ;-). Dodanie nowego użytkownika Zanim się zaczniesz zastanawiać jaki użytkownik ma jakie prawa warto wiedzieć jak dodać nowego użytkownika w systemie Unix, a w szczególności Linux. Standardowa komenda dodająca użytkownika do systemu to useradd. W środowisku graficznym praktycznie każdy Unix, a nawet dystrybucja Linuksa posiada własne narzędzia do zarządzania użytkownikami. W jednej z najpopularniejszych dystrybucji Linuksa czyli Redhat Linux i jego następcy Fedora Core istnieje coś takiego jak User Configuration Tool. Jest to wygodne narzędzie do zarządzania użytkownikami pokazane na obrazku poniżej. Strona domowa User Configuration Tool - http://fedora.redhat.com/projects/config-tools/redhat-config-users.html. Użytkownicy i ich prawa Prawa użytkowników do wykonywania poszczególnych czynności w systemie są uwarunkowane przez ich przynależność do poszczególnych grup oraz poprzez prawa przypisane danemu użytkownikowi. Standardowo wszystkie czynności związane z konfiguracją systemu i wielu programów, może wykonać tylko użytkownik z prawami root. Pakiet Samba jako że operuje na systemie plików jest szczególnie newralgicznym oprogramowaniem w systemach Unix. Cała konfiguracja pakietu Samba jest zawarta w pliku smb.conf (często /etc/samba/smb.conf), którego właścicielem jest użytkownik/grupa root i prawa zapisu ma tylko użytkownik root. Jeśli z jakiś względów chciałbyś dać jakieś grupie możliwość konfiguracji Samby, czyli np. udostępniania udziałów, najprościej jest zmienić właściciela "grupowego" pliku smb.conf na dana grupę i dać jej możliwość zapisu. Rozwiązanie to jest bardzo złe ze względów bezpieczeństwa. Użytkownik, należący do tej grupy przy odrobinie znajomości Samby może zdobyć prawa root w systemie. Poniżej pokazano wynik działania polecenia pdbedit -L -v (Samba 3.0) dla konkretnego użytkownika co wyświetliło nam ustawienia danego konta Samby. W Sambie 3.0.6 doszła jeszcze flaga `Logon hours` czyli możemy zdefiniować godziny logowania dla danego użytkownika. Bazy użytkowników i haseł Bazy użytkowników i haseł zawierają informacje o użytkownikach i hasłach w tym wypadku Samby. Zależnie od tego której bazy haseł użyjemy to będziemy posiadać różnego rodzaju możliwości ustawienia m.in. praw użytkowników. Dodatkowa ważna cecha zależna od bazy to możliwości replikacji tych baz a przez to przydatności dla dużych sieci. Mnogość baz haseł Samby wynika głównie z historii rozwoju tego pakietu a przez to wzrostu oczekiwań użytkowników i administratorów pakietu Samba. Poniżej przedstawiono podział baz haseł i ich krótką charakterystykę zależnie od wersji Samby w której się pojawiła zaczynając od 2.0. Samby 2.0 wspiera dwie bazy haseł: "Czysty Tekst" czyli Plain Text - Nie jest to właściwie baza haseł Samby. gdyż w tym wypadku Samba korzysta z bazy użytkowników i haseł zawartej w systemie Unix/Linux. Owa baza jest zawarta w standardowych plikach systemu /etc/passwd oraz /etc/shadow. Główna wada tego typu bazy to że hasła SMB są przesyłane przez sieć w postaci niezaszyfrowanej czyli czystym tekstem. Oczywiście w ten sposób musi być ustawiona Samba (encrypt passwords = no) jak i klienci Windows. Możesz o tym poczytać w dziale Dodatkowy opis tyczący haseł SMB (kodowanie). Najważniejsza zaleta tego typu rozwiązania to prostota obsługi. Samba nie posiada wtedy własnej bazy użytkowników i haseł, która musi być synchronizowana z systemową gdyż korzysta właśnie bezpośrednio z bazy użytkowników i haseł systemu Unix. Dodatkowo tylko  w tym wypadku Samba może korzystać ze wsparcia PAM (Pluggable Authentication Modules) co często jest nieocenione przy definiowaniu ograniczeń kont. smbpasswd - Plik smbpasswd stał się swego rodzaju standardem Samby, jego główne cechy to prostota oraz możliwość definiowania podstawowych cech konta użytkownika Samby. Owe cechy, a właściwie flagi to możliwość zablokowania konta użytkownika, ustawienie konta bez hasła oraz zaznaczenie że konto jest kontem zaufanej maszyny (przydatne przy kontach maszyn NT w domenach NT). I najważniejsza cecha dla której wprowadzono smbpasswd to szyfrowanie haseł. Ów plik zawiera zaszyfrowane hasła typu LM (zgodne z m.in. Windows 95/98/Me) oraz NTLM (zgodne z m.in. Windows NT 4.0). Niestety kosztem wprowadzenia szyfrowania haseł (encrypt passwords = yes) rezygnujemy z możliwości wykorzystania PAM. Wynika to z fundamentalnych różnic w szyfrowaniu haseł SMB (m.in. LM i NTLM) i Unix (m.in. MD5). Samby 2.2 wprowadziła wsparcie dla kolejnej bazy haseł: ldapsam_compat (Samba-2.2 LDAP Compatibility) - Baza haseł Samby oparta o OpenLDAP powstała w Sambie 2.2 jako odpowiedz na coraz większa potrzebę posiadania elastycznej i wszechstronnej bazy opartej o LDAP. Sam LDAP jest właściwie systemem bazodanowym zoptymalizowanym do szybkich odczytów. Dodatkowo jest wielce elastyczny do składowania danych z uwzględnieniem praw dostępu i bez problemu poddającym się replikacji poprzez LDAP. M.in. dzięki tym cechom jest wykorzystywany jako podstawa Active Directory. Dokładny opis konfiguracji LDAP i Samby zawarty jest pod tym adresem - http://www.unav.es/cti/ldap-smb-howto.html oraz po polsku http://ldap.uni.torun.pl/raporty/ftp/uci/samba-ldap.html. Samby 3.0 rozszerzyła wsparcie o wiele kolejnych baz haseł: tdbsam - Rozszerzona baza użytkowników i haseł, do zastosowań na lokalnych serwerach, oparta na trywialnej bazie (TDB - trivial database), niezalecana do stosowania w środowisku wielo domenowym. Właściwie owe rozwiązanie postało jako rozszerzenie dla starego i dobrego smbpasswd, wzbogacając je o rozszerzenia znane z bazy SAM użytkowników Windows 2000/XP/2003. Dzięki temu Samba 3.0 zyskała prostą bazę użytkowników będącą w pełni zgodną z systemami bazującymi na Windows 2000/XP/2003. Stosowanie tdbsam możliwe jest w sieciach gdzie potrzebujemy zgodności z Windows 2000/XP/2003 ale w sieciach nie większych niż około 250 użytkowników. Powyżej jest już czas na np. OpenLDAP czyli ldapsam. ldapsam - W Sambie 3.0 wprowadzono nową implementacje bazy użytkowników i haseł z nowym formatem Samba schema różniącym się od tego stosowanego w Sambie 2.2. Nowa implementacja LDAP pozwala na dokładniejszą kontrolę oraz na definiowanie wielu ustawień dla poszczególnych użytkowników oddzielnie co we wcześniej wymienionych bazach użytkowników nie jest możliwe. Sam LDAP zapewnia doskonałe wsparcie dla sieci poprzez mechanizmy  replikacji i dzięki temu możliwe jest budowanie skalownego środowiska dla dużych sieci opartych o wiele domen. nisplussam - Baza użytkowników i haseł oparta o NIS+, przydatne tam gdzie już istnieją serwery SUN z NIS+. mysqlsam - Baza użytkowników i haseł składowana w MySQL i z tego powodu bardzo popularna w niektórych środowiskach które opierają się na istniejącej technologii MySQL. pgsqlsam - Baza użytkowników i haseł składowana w bazie PostGreSQL, właściwie podobna do mysqlsam co się objawia nawet w bardzo podobnej konfiguracji. xmlsam - Baza użytkowników i haseł składowana w plikach XML. Tak naprawdę owa metoda składowania użytkowników nie jest użyteczna do normalnej codziennej pracy. Główne jej zastosowanie to narzędzie pdbedit i jego możliwości migrowania miedzy różnymi bazami użytkowników Samby gdzie pliki XML stanowa doskonałe. Dodatkowo xmlsam przydaje się do tworzenia kopii bezpieczeństwa. Ustawienie bazy użytkowników i haseł Zmiana właściwej bazy użytkowników i haseł dokonywana jest w Samba 3.0 poprzez opcje "passdb backend", gdzie ustawiamy jakiej bazy chcemy używać. Jeśli tego nie ustawialiśmy to korzystamy z domyślnego ustawienia zależnego od wersji Samby i systemu na jakim jest zainstalowana. Aby sprawdzić owe ustawienie możesz użyć komendy jak poniżej: testparm -v|grep "passdb backend" Jako wynik zostanie zwrócone ustawienie bazy haseł z jakiej korzystamy w Sambie 3.0. Może to wyglądać m.in. tak: "passdb backend = smbpasswd". Co ciekawe możemy używać wielu różnych rodzajów naraz baz użytkowników i haseł w Sambie 3.0 jak i wielu tych samych rodzajów baz haseł. Może powstać od tego niezły chaos w Sambie jak twojej głowie po przeczytaniu tego co przed chwilą napisałem. Poniżej przedstawiono przykład użycia różnych baz użytkowników: passdb backend = tdbsam, smbpasswd Jak widać powyżej wystarczy rozdzielić przecinkami rodzaje baz. Co najważniejsze nowi użytkownicy będą dodawani tylko do pierwszej wymienionej bazy, a druga zostanie niezmieniona. Jest to szczególnie sensowne rozwiązanie przy migracji z jednej bazy użytkowników do drugiej. Aby używać dwu takich samych rodzajów baz użytkowników należy podać dodatkowo ścieżkę do plików baz, jak w przykładzie poniżej: passdb backend = tdbsam:/etc/samba/passdb.tdb tdbsam:/etc/samba/old-passdb.tdb Miej na uwadze że przy używaniu szczególnie rozbudowanych baz użytkowników takich jak ldapsam, mysqlsam i pgsqlsam, będziesz potrzebował ustawić coś więcej niż tylko powyższą opcje passdb backend. Dla każdej z tych baz istnieje wiele opcji konfiguracji w pliku smb.conf, z reguły związanych z ustawieniami choćby wskazującymi na odpowiedni serwera odpowiednio OpenLDAP, MySQL czy PostGreSQL oraz związanych np. z replikacją. Dodatkowo potrzebujemy na początek tzw. schematy dla danej bazy, które sa z reguły dostarczane wraz z instalacją Samby. Do zarządzania bazą użytkowników i haseł w Sambie 2.0/2.2 używa się głównie komendy smbpasswd, natomiast w Sambie doszła komenda pdbedit która posiada o wiele większe możliwości i jest zalecana szczególnie jeśli przestajemy używać bazy danych typu smbpasswd. Dzięki tej komendzie możesz tez migrować miedzy bazami danych: pdbedit -i smbpasswd -e tdbsam Tyle magii na temat baz użytkowników i haseł w Sambie. Dostęp do konta Standardowo każdy użytkownik nowododany do systemu Unix może się zalogować lokalnie na swoje konto (jeśli posiada przypisaną prawidłową powłokę) ale nie może się zalogować przez sieć SMB czyli do Samby.  Dobrym rozwiązaniem jest dla kont, "sieciowych" przydzielić tylko dostęp z sieci, a dla kont "lokalnych" tylko dostęp lokalny. Cała tajemnica przydzielana dostępu lokalnego (w sensie prawidłowej powłoki) i sieciowego (tyczy SMB) polega na manipulacji plikami passwd i smbpasswd. Dostępu do komputera z sieci SMB - Wystarczy żeby użytkownik dodany do systemu Unix nie był dodany lub miał zablokowane konto w Sambie (manipulacja plikiem smbpasswd) a wtedy nie będzie mógł się zalogować do Samby. Cała zabawa polega na używaniu jako root (superużytkownik) komendy smbpasswd z odpowiednimi przełącznikami: smbpasswd -a użytkownik - dodanie użytkownika Unix do Samby, teraz będzie mógł się dostać poprzez SMB. W Sambie 3.0 możesz też użyć: pdbedit -a -u użytkownik. smbpasswd -d użytkownik - zablokowanie dodanego konta Samby, teraz będzie miał brak dostępu poprzez SMB. smbpasswd -e użytkownik - odblokowanie zablokowanego uprzednio konta Samby, teraz będzie miał znów dostęp poprzez SMB Dostęp do logowania lokalnego - Wpierw wyjaśnienie że jako dostęp lokalny jest rozumiana możliwość zalogowania się do systemu lokalnie czyli posiadanie prawidłowej powłoki Unix co jeśli jest włączone telnet/SSH pozwoli na taki też dostęp. Jeśli dany użytkownik ma mieć tylko dostęp zdalny poprzez sieć SMB (Samba) lub dane konto jest kontem maszyny na Sambie będącym Podstawowym Kontrolerem Domeny NT bezwzględnie zalecane jest przyznanie użytkownikowi tylko dostępu poprzez sieć SMB czyli odpowiadające konto Unix powinno mieć powłokę /bin/false lub /dev/null (manipulacja plikiem passwd). Cała zabawa polega na używaniu jako root (superużytkownik) komendy useradd (dodanie nowego użytkownika) lub usermod (modyfikacja istniejącego użytkownika) z odpowiednimi przełącznikami: useradd/usermod -s /bin/false użytkownik - dodanie/modyfikacja konta użytkownika żeby nie mógł się zalogować lokalnie (tzw. fałszywa powłoka). useradd/usermod -s /bin/bash użytkownik - dodanie/modyfikacja konta użytkownika żeby mógł się zalogować lokalnie (przykładowa powłoka bash). Określenie godzin logowania dla danego użytkownika Od Samby 3.0.6 zostało dodane pole `Logon hours` pozwalające zdefiniować godziny logowania danego użytkownika SMB. Niestety nie udało mi się odnaleźć w dokumentacji jak owe godziny ustawić. jedyna opcja z tym związana to: pdbedit -Z użytkownik - resetuje godziny logowania danego użytkownika. Określenie listy komputerów z jakich dany użytkownik może się logować W Sambie 3.0 zostało dodane również pole `Workstations` pozwalające zdefiniować listę komputerów z jakich dany użytkownik SMB może się logować. Niestety nie udało mi się odnaleźć w dokumentacji jak ową wartość ustawić. Ograniczenia tyczące haseł użytkowników W temacie ograniczeń haseł użytkowników w Samba/Uunix można rozróżnić trzy przypadki: Samba z niekodowanymi hasłami - W systemach Unix można zdefiniować wiele ograniczeń tyczących haseł, kontrolowanych przez biblioteki PAM. Ale żeby skorzystać z tego co oferuje na PAM w Sambie trza użyć niekodowanych haseł. Wynika to z tego że PAM rozpoznaje hasła lub ich hasze MD5 (forma kodowania w Unix) ale nie może rozpoznać kodowanych haseł typu LM/NTLM czyli SMB, wynika to z tego że są to tak naprawdę "skróty" haseł (forma wywołanie/odpowiedź). Przygotowanie Samby sprowadza się do ustawienia dwu opcji w smb.conf: encrypt passwords = no - włącza niekodowane hasła w Sambie obey pam restrictions = yes - włącza kontrole PAM nad kontem i sesją, działa tylko przy niekodowanych hasłach Samba 2.0/2.2 z kodowanymi hasłami - W przypadku włączenia kodowania haseł, baza haseł w Sambie nie podlega już ograniczeniom PAM. Niestety nie jest możliwe przystosowanie bibliotek PAM, do kontroli zakodowanych haseł Samby, gdyż wtedy nie są już używane same hasła ale ich "skróty". Dlatego też nie możemy w Sambie 2.X korzystać z "udogodnień" wymuszających np. odpowiednią złożoność hasła. Nie możemy też ustawić wymuszenia zmiany hasła. Podobnie jest z wymuszaniem zmiany "starego" hasła, ale tutaj jest o tyle łatwiej że w pliku haseł smbpasswd jest zawarty wiek hasła i w oparciu o to można napisać skrypt przypominający np. poprzez Winpopup o zmianie hasła, ale nic więcej. Samba 3.0 z kodowanymi hasłami - Jest to pierwsza wersja Samby która potrafi przy kodowanych hasłach kontrolować "rodzaje" haseł i zarządzanie kontami. Całość polega na używaniu komendy pdbedit (działa tylko z konta root) z przełącznikiem -P  i -C z odpowiednimi zasadami konta: minimum password age - minimalny okres ważności hasła (liczba sekund) reset count minutes disconnect time - czas po którym następuje rozłączenia użytkownika user must logon to change password - użytkownik musi zmienić hasło password history - wymusza tworzenie historii haseł (liczna haseł w historii) lockout duration min password length - minimalna długość hasła (liczba znaków) maximum password age - maksymalny okres ważności hasła (liczba sekund) bad lockout attempt - ilość złych prób logowania zanim konto zostanie zablokowane Składnia wygląda np. tak: pdbedit -P "maximum password age" -C 7776000 , czyli ustawia maksymalny okres ważności hasła na 90 dni (czas podany w sekundach). Zauważ że powyższe zasady są globalne, nie ma możliwości zdefiniowania ich dla poszczególnych użytkowników. Puste hasła Standardowo w Sambie konta nie posiadające haseł (czyli posiadające tzw. "puste hasła") są zablokowane na dostęp z sieci (wyjątek konto "gościnne"). Czyli jeśli udostępniłeś jakiś udział dla konta zdefiniowanego na twojej Sambie i nie nadąłeś temu kontu hasła to standardowo Samba nie wpuści takiego użytkownika poprzez sieć, ewentualnie przerzuci go na konto Gość. Oczywiście nie dotyczy to samego konta Gość. Jest to irytujące w np. sieciach domowych gdzie takie restrykcje nie są często potrzebne, a stają się wręcz niewygodne. Żeby to zmienić, dodaj do pliku konfiguracyjnego Samby smb.conf opcje null password = yes/no - opcja ta odpowiada za zezwolenie lub nie na puste hasła w Sambie. Mapowanie użytkowników i grup miedzy Windows a Samba/Unix W sieci mieszanej czyli złożonej z systemów Windows jak i opartych na Samba/Unix istnieje problem mapowania grup Windows NT na grupy Unix. Samba 2.2 nie dostarcza kompletnego rozwiązania tego problemu, możemy jedynie wskazać dwie podstawowe grupy w domenie NT na odpowiednie grupy Unix. Czynimy to za pomocą opcji globalnych w pliku smb.conf: domain admin users = root Przypisanie użytkownikowi root w systemie Unix mapowania na użytkowników Administratorzy Domeny. domain admin group = root Przypisanie grupy root w systemie Unix mapowania na grupę "Domain Admins" czyli Administratorzy Domeny. Oczywiście zamiast użytkownika bądź grupy root możesz przypisać jakąkolwiek inną. Zauważ że w opcjach Samby 2.2 nie można mapować żadnych innych grup domenowych poza "Domain Admins" czyli Administratorzy Domeny. Jest to rozwiązanie tymczasowe, które w jakiś sposób spełniało swoja rolę do czasu nastania Samby 3.0 gdzie problem mapowania grup został rozwiązany. Sambie 3.0 posiada już pełnoprawne rozwiązanie mapowania grup Windows na grupy Unix. Grupy Unix masz zapisane w Linuksie w pliku /etc/group, wpierw sprawdź jakie są już mapowania w Sambie za pomocą komendy: net groupmap list i zobaczysz w tym w stylu linie: Domain Guests (S-1-5-21-174493983-2430297055-2713686586-514) -> -1 czyli grupa Windows "Domain Guests" , o identyfikatorze (te cyfry ;-) jest zmapowana na -1 (czyli na nic) lub Domain Guests (S-1-5-21-174493983-2430297055-2713686586-514) -> users jest zmapowana na users. W każdym razie modyfikujesz mapowania grup w następujący sposób: net groupmap modify ntgroup="Grupa windowsowa" unixgroup=jakas_grupa_unix Natomiast dodajesz nowe mapowanie jak poniżej: net groupmap add ntgroup="Domain Admins" unixgroup=users no i tyle, wystarczająco żeby zrobić z tym porządek ;-) więcej poczytać możesz w pomocy do komendy net groupmap. Mapowanie użytkowników Windows na użytkowników Unix jeśli są inni możemy wykonać w Sambie 2.2 jak i 3.0 za pomocą pliku map. Definiowany jest on w [global] w smb.conf, przy pomocy opcji: username map = /etc/samba/smbusers Składnia pliku map smbusers wygląda następująco: # Unix_name = SMB_name1 SMB_name2 ... root = administrator admin nobody = guest pcguest smbguest Czyli po lewej stronie nazwa Unix, a po prawej nazwa SMB czyli np. Windows. Jak widać w tym przykładnie jeden użytkownik Unix może posiadać wiele nazw SMB. Uprawnienia udostępniania Udostępniając zasób masz możliwość zdefiniowania praktycznie jednego z trzech poziomów dostępu:  Pełna kontrola ustawiana przez opcje: admin users = user (domyślnie nie zdefiniowane) - lista użytkowników mających przywileje administracyjne w udziale czyli prawa root w operacjach na plikach, czyli dany użytkownik może np. skasować plik nawet jeśli nie ma do tego uprawnień wynikających z systemu plików w Uniksie. Nadawaj te uprawnienie ze szczególną ostrożnością. Zmiana/Zapis ustawiana przez opcje writable = yes (domyślne no) -  określającą że udział jest udostępniony do zapisu oraz ewentualnie write list = user/@grupa (domyślnie pusta wartość) - lista użytkowników mających dostęp tylko do zapisu w udziale. Odczyt ustawiana przez opcje read ony = yes określającą że udział jest udostępniony do tylko do odczytu oraz ewentualnie read list = user/@grupa (domyślnie pusta wartość) - lista użytkowników mających dostęp tylko do odczytu w udziale. Dodatkowo możemy użyć jeszcze m.in. opcji udziałów: host allow/ host deny = 192.168.1.1/nazwa_kompa (domyślnie brak wartości) - lista komputerów (po adresach IP lub nazwach) mających zezwolenie lub nie w dostępnie do usługi force user/group = user/grupa (domyślnie nie zdefiniowane - podłączenie jako wymuszony użytkownik/grupa przy dostępnie do udziału force user/group = user/grupa (domyślnie nie zdefiniowane - podłączenie jako wymuszony użytkownik/grupa przy dostępnie do udziału guest ok = yes/no (domyślnie no) - dostęp gościny do usługi guest only = yes/no (domyślnie no) - wymuszanie podłączenia jako gość w dostępnie do udziału valid/invalid users = user (domyślnie nie zdefiniowane) - lista użytkowników mających lub nie zezwolenie na logowanie się do danej usługi Uprawnienia systemu plików (UNIX) W systemach Unix (min. w Linuksie) każdy plik/katalog musi posiadać właściciela i właściciela grupowego i mogą oni być zmieniani tylko przez użytkownika z prawami administratora czyli dla Linuksa jest to standardowo root. Uprawnienia systemu plików są typu "trzy na trzy", czyli każdy plik (katalog) może mieć przypisane uprawnienia tylko dla jednego użytkownika (właściciel), tylko jednej grupy (właściciel grupowy) oraz tzw. inni czyli "reszta świata". Każdemu z nich można przypisać najwyżej trzy uprawnienia czyli: odczyt (r), zapis (w), wykonanie (x, a w przypadku katalogów jest to możliwość wejścia - X). Taki rodzaj uprawnień jest przejrzysty ale też mało elastyczny szczególnie w porównaniu do list kontroli dostępu (ACL) znanych z rodziny systemów Windows NT. Dodatkowo możesz ustawić bity specjalne: UID czyli ID użytkownika -  Program ten będzie wykonywany z prawami użytkownika do jakiego należy a nie z prawami użytkownika jaki go uruchomił. GID czyli ID grupy - Program ten będzie wykonywany z prawami grupy do jakiej należy a nie z prawami grupy użytkownika jaki go uruchomił. Bit "sticky" inaczej bit przyklejony, lepki - obecnie ma zastosowanie tylko do katalogów "współdzielonych" takich jak np. /tmp gdzie każdy użytkownik ma prawo zapisu ale dzięki temu bitowi nie mogą oni nawzajem modyfikować swoich plików. Do zmiany uprawnień z linii poleceń czyli w konsoli służy polecenie chmod, natomiast do zmiany właściciela służy komenda chown (zmiana właściciela) i chgrp (zmiana grupy właściciela). Oczywiście przeczytaj pomoc czyli manuale do tych poleceń. Poniżej pokazano pomoc dla komendy chmod. Listy kontroli dostępu (POSIX ACL) w systemach Unix Często używanym argumentem użytkowników systemów Windows z linii NT jest to, że model bezpieczeństwa oferowany przez systemy Unix, typu 3 na 3 (w uprawnieniach systemu plików opisanych powyżej), jest zbyt mało elastyczny. Standardowy model uprawnień 3 na 3 może spełnić swoje zadanie tylko przy małej ilości użytkowników i grup, którzy nie są zbyt wymagający. W większych środowiskach lub gdzie wielu użytkowników potrzebuje pracować i zapisywać zmiany na wspólnymi plikami, przydadzą się na Listy kontroli dostępu czyli ACL w systemach Unix. Warto używać list kontroli dostępu czyli ACL, zamiast standardowych uprawnien 3 na 3 co najmniej z dwu powodów: POSIX ACL rozszerzają standardowe uprawnienia 3 na 3 (odczytywanie, zapisywanie, wykonywanie dla jednego użytkownika, grupy, innych) do systemu 3 na X (odczytywanie, zapisywanie, wykonywanie dla wielu niezależnych użytkowników, grup, innych). POSIX ACL, dalej oferuje trzy rodzaje uprawnień ale za to, można nadawać owe uprawnienia dla wielu niezależnych użytkowników i grup. Czyli jak widać POSIX ACL zupełnie różni się od ACL znanych z Windows z systemem plików NTFS, a przez to sprawia to pewne problemy przy wzajemnym mapowaniu ACLi w Sambie. POSIX ACL nie psują obecnego już w systemie systemu uprawnień 3 na 3, tylko je rozszerzają. Dzięki temu jeśli w systemie z obsługą ACLi zaczniesz ustawiać te uprawnienia, zostaną one dodane do już standardowych. Jesli natomiast zamontujesz system plików (dysk, partycje) na której zdefiniowano jakieś uprawnienia poprzez ACL, w systemie bez obsługi owych ACLi, zostaną one po prostu zignorowane i nie będą widoczne żadne uprawnienia ponad standardowe 3 na 3. Świat systemów Unix, w większości wypadków, korzysta z systemu ACL zgodnego z POSIX. Nie ma co prawda do dziś oficjalnego zatwierdzonego standardu POSIX, dotyczącego ACL ale są tzw. szkic standardu czyli draft. System List kotroli dostępu czyli ACL, opiera się dokładnie na dokumentach 1003.1e Draft 17 (System Application Programming Interface) oraz 1003.2c (Shell and Utilities). Aby można było używać POSIX ACL w danym systemie Unix, potrzebne są trzy elemnty: Wsparcie ze strony systemu dla ACL (czyli w jego jądrze - kernelu). Narzędzia w przestrzeni użytkownika do manipulowania uprawnieniami ACL. Wsparcie dla ACL w danym systemie plików, który musi być podmontowany z opcją wsparcia dla ACL. Aby spełnić pierwszy warunek czyli wsparcie ze strony systemu dla ACL, wystarczy użyć odpowiedniego systemu Unix. Poniżej jest lista systemów Unix wspierających listy kontroli dostępu ACL: Solaris 2.6 i późniejsze - z własną wersją systemu plików UFS. SGI Irix - z natywnym systemem plików XFS IBM AIX - system firmy IBM, dla którego powstał system plików JFS1, następnie JFS2, adoptowany do innych systemów Unix jako po prostu JFS. HP/UX 11.0 i późniejsze - z systemem plików JFS 3.3 (poprawnie VxFS z Veritas Software, nie mylić z JFS od IBM) oraz z Hi Performance FileSystem (HFS jestm wariantem UFS) . HP/UX jest pierwszym system Unix, wspierający ACL. Mac OS X od wersji 10.4 i późniejsze, chociaż implementacja owa nie jest w pełni zgodna z POSIX ACL. FreeBSD 5.0 i późniejsze. ACL pojawiły się w nim dzięki projektowi TrustedBSD (www.trustedbsd.org). Linux z kernelami 2.6 (standardowo od 2.5.46) oraz istnieją łatki dla kerneli 2.4. Pierwszy system plików w Linuksie ze wsparciem ACL to XFS - który wspiera je niejako naturalnie, następnie za pośrednictwem atrybutów rozszerzonych i łatkom na jądro (kernel) autorstwa Andreas Grünbacher (http://acl.bestbits.at), zostały zaimplementowane w systemie plików Ext2 oraz systemach plików z księgowaniem Ext3, Reiserfs, JFS. Polecam lekturę artykułu POSIX Access Control Lists on Linux - http://www.suse.de/~agruen/acl/linux-acls/online/. Linux i POSIX ACL W systemie Linux, w praktycznie każdej nowoczesnej dystrybucji z kernelem 2.6 jest włączone wsparcie dla ACL w systemach plików. Jednak jakbyś z jakiś powodów musiał samodzielnie przygotować jądro systemu (kernel) należy w File systems, zaznaczyć odpowiednie opcje (POSIX_ACL i XATTR) przy odpowiednich systemach plików, tj.:  Dla systemów plików Ext2, Ext3, JFS i Reiserfs, zaznacz opcje extended attributes (XATTR) czyli atrybuty rozszerzone oraz w nim POSIX Access Control Lists (POSIX_ACL). Dla systemu plików XFS, wystarczy zaznaczyć tylko POSIX ACL support, gdyż w nim owa właściwość jest jakby naturalna. Następnie musisz się zatroszczyć o narzędzia w przestrzeni użytkownika do manipulowania uprawnieniami ACL czyli chacl, getfacl i setfacl). Owe narzędzia zawarte są w pakiecie acl i powiązanej z nią bibliotece libacl. W przypadku dystrybucji Linuksa opartej na pakietach rpm możesz sprawdzić czy zainstalowane sa te pakiety poprzez wydanie komendy: # rpm -qa|grep acl libacl-2.2.39-2.1.el5 acl-2.2.39-2.1.el5 Trzecie element układanki, jak już wspomniano to zamontowanie systemu plików ze wsparciem dla ACL. Czyli w pliku /etc/fstab, nalezy dodac wpis acl, czyli powinno wyglądać to tak: /dev/sda1      /home     ext3      defaults,acl     1 2 Można oczywiście po prostu użyć komendy mount czyli: mount -o remount,acl /dev/sda1 Użycie ACL w systemie Linux odbywa się poprzez komendy chacl, getfacl i setfacl. Poprzez komendę getfacl sprawdzamy listy kontroli dostępu: getfacl test.txt # file: test.txt # owner: root # group: root user::rw- group::r-- other::r-- Ustawiamy listy kontroli dostępu na trzy sposoby: poprzez komendę setfacl co nadpisuje istniejące listy kontroli dostępu: poprzez komendę setfacl z opcją -m co modyfikuje istniejące listy kontroli dostępu: dodanie uprawnień dla użytkownika lisa setfacl -m u:lisa:r test.txt poprzez komendę chacl do modyfikowania istniejącej listy kontroli dostępu: podstawowe ustawnie uprawnień, takie jak chmod chacl u::rwx,g::r-x,o::r-- test.txt dodanie uprawnień dodatkowo poza właścicielem dla użytkownika bob chacl u::rwx,g::r-x,o::r--,u:bob:r--,m::r-x test.txt   FreeBSD i POSIX ACL W systemie FreeBSD od wersji 5.0  istnieje wsparcie dla ACL, które pojawiło się w nim dzięki projektowi TrustedBSD (www.trustedbsd.org). FreeBSD standardowo używa jako swojego natywnego systemu plików UFS (dawniej, do wersji 5.0) oraz UFS2 (obecnie, od wersji 5.1). UFS (Unix File System) jest jednym ze starszych i szybszych systemów plików w systemach Unix. UFS powstał gdzieś w okolicach 1994 roku dla czegoś co można nazwać oryginalnym BSD. Obecnie chyba każdy system BSD posiada wsparcie dla UFS, problem w tym że często jest o jego własne UFS, niekoniecznie kompatybilne z innymi systemami UFS z innych systemów BSD. Obecnie główne implementacje systemu UFS, posiadające często własne cechy: SunOS/Solaris - UFS m.in. z księgowaniem, wsparciem dla dużych plików i dużych dysków. Mac OS X - od wersji systemu 10.4, wspiera UFS obok własnego HFS+ FreeBSD, NetBSD, OpenBSD i pochodne darmowe BSD - UFS1 wywodzący się z 4.4BSD i UFS2 zaimplementowany we FreeBSD i przeportowany do NetBSD z tzw. softupdates, wsparciem dla dużych wolumenów, atrybutami plików oraz rozszerzonych flag.. Od wersji FreeBSD 8 UFS2, będzie obsługiwał również księgowanie. HP/UX ze swoim wariantem UFS, zwanym jako Hi Performance FileSystem oraz Tru64 UNIX Oczywiście nas w tym momencie interesuje implementacja UFS we FreeBSD, cała reszta została podana aby mieć świadomość jak szerokim terminem jest UFS. Aby włączyć ACL w FreeBSD 5.0 z systemem plików UFS1, należy: przygotować i zainstalować kernel z opcjami związanymi z atrybutami rozszerzonymi, czyli UFS_EXTATTR oraz UFS_EXTATTR_AUTOSTART. zainicjować atrybuty rozszerzone w danym systemie plików: % mkdir -p /var/.attribute/system % cd /var/.attribute/system % extattrctl initattr -p /var 388 posix1e.acl_access % extattrctl initattr -p /var 388 posix1e.acl_default uruchomić ponownie system i cieszyć się ACL Cała procedura jest opisana pod następującym adresem - http://www.onlamp.com/pub/a/bsd/2003/08/14/freebsd_acls.html. Aby włączyć ACL w FreeBSD 5.1 i późniejszymi z systemem plików UFS2, należy: domyślnie kernel jest przygotowany z opcją UFS_ACL uruchomić system w trybie single user, jeśli chcemy właczyć ACl na działającym systemie plików odmontować partycje na której działamy, włączyć ACL poprzez tunefs i zamontować ponownie: # /sbin/umount /usr # /sbin/tunefs -a enable /dev/ad0s1f tunefs: ACLs set # /sbin/mount /usr nastepnie po powrocie do normalnej pracy, możesz poprzez komendę mount sprawdzić czy to działa, wynik powinien być podobny do poniższego: /dev/ad0s1f on /usr (ufs, local, soft-updates, acls) Cała procedura jest opisana pod następującym adresem - http://www.onlamp.com/pub/a/bsd/2005/09/22/FreeBSD_Basics.html oraz na stronie podręcznika http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/fs-acl.html. Użycie ACL w systemie FreeBSD podobnie jak w Linux odbywa się poprzez komendy chacl, getfacl i setfacl. SAMBA ACL Używając Samby możesz korzystać z zalet list kontroli dostępu (ACL) znanych z systemów Windows NT/2000/XP/2003. Problem w tym że Samba używa POSIX ACL a klient Windows używa swojego własnego spojrzenia na ACL. Różnice są znaczące, choćby w POSIX ACL nie ma czegoś takiego jak Zabroń, można ustawić tylko Zezwól. Dodatkowo systemy Windows od czasu Windows 2000 posiadają wiele rozbudowanych ACLi jak choćby przejecie uprawnień do plików, które nie występują w POSIX ACL. W każdym razie nawet klient Windows może modyfikować ACLe na udziałach Samby w zakresie dopuszczalnym poprzez POSIX ACL czyli odczyt, zapis, wykonanie dla wielu różnych użytkowników i grup. Samba musi być skompilowana z opcją --with-acl-support żeby mogła korzystać z ACL. Jeśli owe warunki masz spełnione możesz cieszyć się listami kontroli dostępu (ACL) w Sambie odpalonej na twoim systemie Unix. Poniżej wymieniono opcje Samby odpowiedzialne za konfiguracje ACL. Wszystkie te opcje możesz podać albo w sekcji ustawień globalnych lub tylko dla danego udziału Samby. nt acl support = yes/no - jeśli ustawiona na `yes` (standardowe ustawienie) włącza możliwość ustawiania i kontrolowania list ACL dla udziałów. security mask = 0777 - (domyślnie) Maska uprawnień plików (w odniesieniu do modelu Unix 3 na 3), jakie mogą być modyfikowane bądź nie przez klienta. Gdy ustawisz 0000 wtedy nie będzie możliwa żadna modyfikacja list ACL. force security mode = 0000 - (domyślnie) Bit uprawnień plików (w odniesieniu do modelu Unix 3 na 3) jaki będzie zawsze ustawiany gdy będą modyfikowane listy ACL  przez klienty Windows NT/2000/XP/2003. Standardowe ustawienie pozwala użytkownikom zmieniać i usuwać jakiekolwiek uprawnienia plików. directory security mask = 0777 - (domyślnie) Maska uprawnień katalogów (w odniesieniu do modelu Unix 3 na 3), jakie mogą być modyfikowane bądź nie przez klienty Windows NT/2000/XP/2003. Gdy ustawisz 0000 wtedy nie będzie możliwa żadna modyfikacja list ACL. force directory security mode = 0000 - (domyślnie) Bit uprawnień katalogów (w odniesieniu do modelu Unix 3 na 3) jaki będzie zawsze ustawiany gdy będą modyfikowane listy ACL  przez klienty Windows NT/2000/XP/2003. Standardowe ustawienie pozwala użytkownikom zmieniać i usuwać jakiekolwiek uprawnienia katalogów. Listy kontroli dostępu (ACL) możesz zmieniać nie tylko poprzez klienty Windows NT/2000/XP/2003 ale tez z poziomu systemów Unix. Służy do tego narzędzie z pakietu Samba o nazwie smbcacls dostępne w wersji 2.2 i 3.0. Oczywiście zanim go użyjesz, przeczytaj pomoc czyli manual do tego polecenia. Poniżej pokazano pomoc dla komendy smbcacls.