FreeBSD ACL
Wpisany przez crash poniedziałek, 17 października 2005 19:05
Pięć lat temu (wow, to było tak dawno ?), napisałam artykuł: "Zrozumieć prawa dostępu w Unix'ie".
Od tego momentu w FreeBSD zaimplementowano coś co sie nazywa ACL (Access Control List).
ACL'e pojawiły sie w BSD jako część projektu TrustedBSD. Tak jak nazwa wskazuje dali użytkownikom doskonalszy dostęp nad prawami dostępu.
Dlaczego powinienem używać ACL ?
- ACL nie zmieniaja standartowych praw dostępu w Unix'ie czyli (r)ead, (w)rite, e(x)ecute
- Dają lepszą kontrolę nad plikami niż tylko te dla których są przypisane.
Mały przykład, jako zwykły użytkownik, stwórz plik o nazwie <i>test</i> w tymczasowym katalogu.
| % touch /tmp/test % ls -l /tmp/test -rw-r--r-- 1 dru dru 0 Jul 26 15:43 /tmp/test |
Wybrałam ten katalog ponieważ wszyscy użytkownicy maja prawa zapisu do tego katalogu i jest to dobre miejsce do testowania praw dostępu. Jednak nie trzymaj tam żadnych ważnych plików, ponieważ mogą one zniknąć, w zależności jak administrator systemu ustawił czyszczenie tego katalogu!
W tym przykładzie, właścicielem pliku jest dru, posiada prawa rw ( zapis, odczyt ), grupa dru posiada dostęp do czytania ' r ' oraz inni posiadają prawo czytania ' r '. Zauważ że przy tworzeniu użytkownika w FreeBSD, dostajesz możliwość wyboru nazwy grupy np. nazwa twojego użytkownika.
Teraz przypuśćmy, że potrzebuję dać prawa zapisu dla użytkowników ' rob ' i ' toby '. W bieżącej postaci, mogą oni jedynie otworzyć go w edytorze, ale nie maja praw aby zapisać czegokolwiek do tego pliku.
Zanim użyjemy ACL, powstaje podstawowy dylemat, zmodyfikowania grupy.
Mogłabym, na przykład, poprosić administratora systemu aby dodał użytkowników ' rob ' i ' toby ' do grupy ' dru '. Wtedy można użyć chmod do dodania praw zapisu dla grupy. To jest lepsze rozwiązanie niż danie praw zapisu dla ' other ', ponieważ każdy w systemie miałby dostęp do zapisu tego pliku.
Alternatywnie, administrator systemu może ostrożnie zaplanować, którzy użytkownicy potrzebuja dostęp do pliku a następnie stworzyć odpowiednia grupę. Następnie przypisać grupę do danego pliku.
Jednak, żaden system nie jest doskonały. Po pierwsze, bedzie to wkurzalo administratora, ponieważ bedzie do dla niego badzo kłopotliwe aby modyfikować ciągle prawa do plików.
Dalej, rozważmy inny scenariusz. Przypuśćmy ze dru, rob i tobby należą do nowo powstałej grupy ' workgroup '. Wszyscy ci trzej użytkownicy mogą zapisywać do wszystkich plików które maja przypisaną grupę ' workgroup '. Ale co, jeżeli dru chce aby rob mial zapis do jednego z tych plików ale aby nie mógł toby ?
W tym momencie zaczyna sie komplikować. Na szczęście z pomocą przychodzi ACL. Bez prośby administratora o tworzenie nowych grup lub użycia ' chgrp ', dru może łatwo zdecydować kto może mieć prawa do plików.
Ten artykuł pokaże ci, w jaki sposób administrator systemu może łatwo przystosować FreeBSD do obsługi ACL. Tak więc ja zademonstruje narzedzie graficzne, które pozwoli twoim użytkownikom łatwo kontrolować ACL na ich plikach. Końcowo, pokażę ci w jaki sposób stworzyć kopię zapasową ACL'i.
Przygotowanie systemu
Jeżeli używasz FreeBSD 5.1 lub nowszych, ACL jest wspomagane i wbudowane w system oraz w system plików UFS2.
( Jeżeli używasz wcześniejszych wersji FreeBSD, przeczytaj artykuł Daniela Harris'a )
Zaczynając, musisz zdecydować jedynie na której partycji(-ach) chciałbyś używać ACL.
| # df Filesystem 1K-blocks Used Avail Capacity Mounted on |
W moim systemie, chcę włączyć ACL jedynie dla użytkowników, tak więc skonfiguruję partycję ' /usr '.
FreeBSD Handbook wyjaśnia zalety używania komendy <i>tunefs</i> aby włączyć ACL. Wada tego jest taka, iż należy uruchomić system w trybie single-user i odmontować system plików. Wybierz odpowiednią porę kiedy użytkowników jest najmniej oraz wykonaj:
| # shutdown now Enter full pathname of shell or RETURN for /bin/sh: # /sbin/umount /usr |
Użyj komendy ' df ', aby niepomylić nazwy użądzenia na którym chcesz włączyć ACL.
Następnie zobacz czy działa.
| # /sbin/mount /dev/ad0s1a on / (ufs, local) devfs on /dev (devfs, local) /dev/ad0s1e on /tmp (ufs, local, soft-updates) /dev/ad0s1f on /usr (ufs, local, soft-updates, acls) /dev/ad0s1d on /var (ufs, local, soft-updates) |
# exit
To wszystko, teraz ACL działa na partycji /usr.
Instalacja środowiska graficznego
Jeżeli wpiszecie w Google "FreeBSD acl", znajdziecie pare artykułów typu "How to". Każdy z nich przedstawia konfigurację ACL wykorzystując narzedzia ' getfacl ' oraz ' setfacl ', jak np. świetny artykuł Grzegorza Czaplińskiego ' Working with ACLs in FreeBSD 5.x '.
O ile ' getfacl 'jest prosty, składnia ' serfacl ' bywa czasami uciążliwa, na tyle że może wystraszyć swoich użytkowników. Przedstawiam tutaj zalety środowiska graficznego, który pozwoli w łatwy sposób wywołać i kontrolować prawa dostępu.
eiciel udostepnia narzędzie graficzne które jest intuicyjne, dostępne jest ono w paczkach jak również w portach. Również działa na systemach Linux, narzedzie to jest dostępne w zakładce menadżera plików Nautilus, który jest dość przyjazny.
Możesz szybko dodać paczke:
# pkg_add -r eiciel
Jak już zainstalowałeś paczke, wyjdź z konta superużytkownika i włącz X'y.
Uruchomienie GUI
Są dwie drogi, aby uzyskać dostęp do niedawno zainstalowanego środowiska graficznego. Pierwszy, należy uruchomić ' nautilus '
Rysunek 1. Użytkownik ' dru ' ma trzy pliki w swoim katalogu domowym, które sie nazywają: test, file1 oraz myfile.
Rysunek 2. Pokazuję co widać w momencie klikniecia na właściwości pliku test.
Rysunek 1. Wyświetlenie plików w narzedziu Nautilus
Rysunek 2. Wyświetlenie właściwości pliku w Nautilus
Instalacja eiciel dodała zakładkę ' Access Control List ' do Nutilus'a. W zakładce tej są wyświetlone prawa dostępu adekwatne do tych niżej co widać:
| % ls -l test |
Drugą metodą jest uruchomienie samego ' eiciel ' ( Rysunek 3 ). Kliknij w przycisk ' Open ', a następnie wybierz plik test ( Rysunek 4. ). Po wybraniu pliku pokaże się lista dostępu do pliku ( Rysunek 5. ).
Rysunek 3. Uruchomiony eiciel bezpośrednio
Rysunek 4. Otwierani pliku test
Rysunek 5. Edycja list dostępu w eiciel
Osobiście wolę używać ' nautilus ', który ma dodatkowo zakładkę ' Permissions ', która udostępnia mi przeglądanie i zmianę:
- właściciela pliku
- grupy, podobne użycie jak chgrp
- specjalne flagi, kontrola SUID, SGID, oraz sticky bit
- tekstowy wygląd, podobny do ' ls -l '
- numer widoku, w tym przypadku, 644
Zrozumienie masek ACL
Spójrz ponownie na Rysunek 2. Tutaj możesz wyświetlić użytkowników i grupy w systemie. Podwójne klikniecie na użytkownika ' rob ', doda dwa nowe elementy do okienka ACL. ( Rysunek 6. )
Rysunek 6. Dodatkowe elementy dla użytkownika ' rob '
Notka: Następne wersje eiciel będą zawierały check box'a który wyłączy konta systemowe.
Zauważ że początkowo rob i mask maja pełne prawa rwx, jest to więcej niż ma dru jako właściciel pliku. Co się stało ? Poprzez podwójne kliknięcie na ' rob ', dodałam ACL, co mogę sprawdzić w liście plików w katalogu.
| % ls -l drwx------ 2 dru dru 512 Jul 26 10:35 Desktop -rw-r--r-- 1 dru dru 0 Jul 27 9:22 file1 -rw-r--r-- 1 dru dru 0 Jul 27 9:22 myfile -rw-r--r--+ 1 dru dru 0 Jul 27 10:03 test |
Widzisz ' + ', na końcu praw dostępu przy pliku test ? Wskazuje to na to że ACL zostały dodane do pliku. Mogę wyświetlić je za pomoca getfacl:
| % getfacl test #file:test #owner:1001 #group:1001 user::rw- user:rob:rwx group::r-- mask::rwx other::r-- |
Wynik jest reprezentacją tekstową Rysunku 6.
Dlaczego rob uzyskał rwx, i co to jest za wpis Mask ? Z definicji, maska ACL określa maksymalne dostępne prawa dostępu. Dzieje się tak, aby upewnić sie że wiesz co robisz w pełni.
Odznacz prawa wykonywania ( execute ) pliku z wpisu dla użytkownika ' rob '. Zauważ że mogę dać jaką kolwiek kombinację, czytania, zapisu, wykonywania. Z perspektywy osoby używającej tego narzedzia, może ona bardzo prosto zmienić prawa dostępu do pliku i zmienić te których nie chce aby ten uzytkownik używał.
Co sie stanie jeżeli zmienisz maskę ? Przywróć ponownie prawa dostępu ( rwx ) dla użytkownika 'rob ', i jednocześnie usuń prawo wykonywania pliku ( execute ). Jak tylko to zrobisz, wykonanie jakiego kolwiek pliku przez użytkownika rob lub jakiego kolwiek, pokaże czerwony znak oszczegawczy. Co bedzie znaczylo " nieefektywne prawa ".
Troche bardziej sie rozjaśnia, jeżeli wrócisz do definicji maski ACL. Teraz maksymalne dostępne prawa są <i>rw</i>, co znaczy że komukolwiek kto ma dostępne prawa wykonywania pliku, tak naprawde nie ma. Narzędzie Nautilus, ukazuje to przyjemnie, getfacl również wskazuje efektywne prawa dostępu.
| % getfacl test #file:test #owner:1001 #group:1001 user::rw- user:rob:rwx # effective: rw- group::r-- mask::rw- other::r-- |
Zrozumieć ACL dla katalogów
Plik może mieć tylko jedną access listę. Większość użytkowników była by zadowolona z możliwości automatycznej zmiany praw dostępu w momencie utworzenia pliku, w ten sposob jak bylo przedstawione w części 3.
Katalogi są bardziej kompleksowe, ponieważ maja trzy typy ACL:
- "access ACL" dostęp do katalogu dla siebie samego
- "default directory ACL" ustawia domyślne prawa dostępu do podkatalogów nowo stworzonych
- "default access ACL" uswiawia domyślne prawa do plików jakie są tworzone w katalogu. W momęcie gdy "default directory ACL" nie są ustawione, podkatalogi będą tworzone z tymi prawami, w momecie jak sa ustawione prawa zostaną nadpisane.
Obecna implementacja FreeBSD wspiera tylko dwa pierwsze typy, praw dostępu do katalogu, tak więc na nowo stworzony plik należy 2 razy kliknąc i dodać go do lity ręcznie.
Aby zobaczyć jak to działa, stworzę katalog ' folder '.
Notka: Jeżeli planujesz zmieniać prawa do katalogu, zrób to zanim dodasz do tego katalogu jakiekolwiek pliki lub podkatalogi. W momencie jak zrobisz odwrotnie, pliki i podkatalogi przejmą nowe ustawienia ACL. Jeżeni tak sie stanie musisz sprawdzić ustawienia twoich plików i podkatalogów.
Spójrz na właściwości ACL katalogu ' folder ' ( Rysunek 7 ). Wygląda podobnie jak właściwości plików, z wyjątkiem guzika " Default ACL ", który nie jest szary i jest jeszcze jeden check box ' Default ' poniżej listy uzytkowników.
Rysunek 7. Właściwości ACL katalogu.
Rysunek 8. Ustawienie domyślnych właściwości
Kliknij guzik "Default ACL", tak jak jest pokazane na rysunku 8. teraz są cztery ustawione wpisy.
| % getfacl folder #file:folder #owner:1001 #group:1001 user::rwx group::r-x other::r-x % mkdir folder/subfolder % touch folder/testfile % ls -l folder drwxr-xr-x+ 2 dru dru 512 Jul 27 12:23 subfolder -rw-r--r--+ 1 dru dru 0 Jul 27 12:23 testfile |
Zauważ że podfolder przejoł prawa dostępu ACL, ale plik nie.
Dodawanie użytkowników do ACL katalogu
Jeżeli wrócę do właściwości katalogu ' folder ', oraz dodam użytkownika ' rob ', czy bedzie miał prawa zapisu do ' folder/subfolder ' oraz ' folder/testfile ' ?
Lepiej dla ciebie jak odpowiesz nie. Ta zmiana w ACL, będzie działała w momecie jak podkatalogi i pliki zostały stworzone po zmianie w ACL.
Również mam wybór jak dodam użytkownika ' rob '. Jeżeli podwójnie klinke na ' rob '. Dam prawa dostępu do katalogu jedynie dla ' rob '. Inaczej mówiąc, zmienię pierwszy typ ACL. Jeżeli najpierw zaznaczę opcję "Default" a następnie dodam ' rob ', zmienię drugi typ dostępu, czyli umożliwię mu prawa do podkatalogów. Mogę dodać go na oba sposoby. Jeżeli w ikonce jest literka D, umożliwa to dostęp do podkatalogów, w momecie jak jej nie ma to użytkownik ma dostęp jedynie do danego katalogu.
Do zademonstrowania, dodam dwa razy użtkownika ' rob ' i ustawie w obu przypadkach prawa <i>rwx</i>. W tym celu stworzę dodatkowy plik i podkatalog.
| % mkdir folder/subfolder2 % touch folder/testfile2 |
Rysunek 9 przedstawia efektywne ACL. Tak jak sie można było spodziewać domyślne prawa ACL sa widoczne przy ikonce rob ( D ), dziedzicząc prawa rwx z głównego katalogu. Zauważ że dostęp ACL widoczny przy ' rob ' bez liteki D w ikonie, pokazuje nieefektywne prawo zapisu ( czerwony wykrzyknik ). Inaczej, tak sie dzieje ponieważ rob został dodany do listy dostępu wcześniej jedynie do samego głównego katalogu i te prawa dostępu nie zostały odziedziczone dla podkatalogów. Możesz zmienic te prawa zaznaczając opcje ' write ' dla Maski.
Rysunek 9. Efektywne ACL
Ok, mamy wyjaśnione w jaki sposób dawać dostęp do podkatalogów, ale co z plikiem ' testfile2 ' ? Spójrz na Rysunek 10. zauważ że nie ma ikonki z literką D, jest to oczywiste z powodu braku wsparcia dla takiego typu ACL, co za tym idzie, pliki nie przejmują praw dostępu z ACL ustawionych dla katalogu. Aby zmienić prawa dostępu dla tego użytkownika, zmień prawa dla maski a następnie zatwierdź dla użytkownika klikając podwójnie na maskę, oraz sprawdź podwójnie czy inni użytkownicy nie maja zmienionych praw.
Rysunek 10. Pliki i domyślne ustawienia dla katalogów
Tworzenie kopii zapasowej ACLi
Jeżeli zdecydowałeś się używać ACL, musisz również pamietać o solidnej kopii zapasowej. Najlepszym rozwiązaniem jest instalacja narzędzia <b>/usr/ports/archivers/star</b> z kolekcji portów. Jeżeli używałeś wcześniej narzędzia do kompresji ' tar ' nie powinno to zająć zbyt wiele czasu.
W tym przykładzie, superużytkownik tworzy katalog kopii zapasowej należący do użytkownika dru który chce stworzyć kopię:
| # mkdir -p /usr/backups/dru # chmod dru:dru /usr/backups/dru # exit |
Następnie dru, tworzy kopię zapasową swojego katalogu uwzględniając ACL:
| % whoami dru % cd % star -cv -Hexustar -acl -f /usr/backups/dru/home.tgz . |
Teraz dru, chce przywrócić pliki w tymczasowym katalogu:
| % mkdir ~/tmp % cd ~/tmp % star -xv -Hexustar -acl -f home.tgz |
Uwaga: Jeżeli chcesz przywrócić pliki do katalogu który znajduje sie na partycji bez uruchomionych list dostępu, pliki beda miał zwykłe prawa pozbawione ACL.
Wnioski
Wielu użytkowników nie slyszało wcześniej o zaletach jakie niesie używanie ACL, lub uważają że jest za trudne do używania. Spędziłąm pół godziny aby pokazując użytkownikom, w jaki sposób używać narzędzia <b>eiciel oraz star</b>, i teraz sie zastanawiają w jaki sposób mogli żyć bez Access Control List.
--
Tekst ten jest tłumaczeniem artykułu Dru Lavigne za jej zgodą - " Using FreeBSD's ACLs ", który ukazał się na stronie O'Reilly. Jeżeli pojawiły się jakiekolwiek niezgodności proszę o kontakt.