Homed: od teraz systemd potrafi zarządzać także katalogami domowymi

Celem komponentu homed jest rozwiązanie pewnych problemów technicznych z katalogami domowymi istniejącymi "po prostu" jako katalogi w /home lub innym miejscu zdefiniowanym w passwd lub LDAP. Problemem tym (systemd widzi problemy wszędzie) jest brak centralizacji i zależność od rozproszonych komponentów.

Patrząc przez pryzmat celu ostatecznego, jakim jest system operacyjny-jako-firmware oraz systemy bezstanowe, koncepcja dostarczania katalogu domowego wymaga konfiguracji źródeł poświadczeń, dostępności autentykatora, systemu uprawnień oraz miejsca w systemie plików. Jednocześnie. Innymi słowy, miesza stan i konfigurację.

Wpięcie linuksowej maszyny do jakiejkolwiek "domeny", niech to będzie FreeIPA, 389DS czy nawet Microsoft Active Directory, rozprasza zarządzanie katalogami domowymi do poziomu, na którym nie wiadomo, kto za nie odpowiada. Pam? A może sssd? Albo /usr/libexec/accounts-daemon, nie daj Boże? I jaki jest fallback takiego scenariusza, jak coś się zepsuje? Czy użytkownik staje się bezdomny i musi się udać na wygnanie? Tak wiele pytań... A podobno identity management wprowadza centralizację.

Systemd radośnie dostarcza rozwiązanie tego problemu, w postaci skonteneryzowanych katalogów domowych, definiowanych przez manifest JSON! Demon homed dokonywałby dźwigania ciężarów związanego z mapowaniem zarządzania tożsamością/logowaniem z zasobami katalogu domowego oraz rozróżnianiem UIDów. Ma przy okazji zapewnić szyfrowanie LUKS z wykorzystaniem hasła.

Manifesty JSON, definiujące użytkowników i poświadczenia na potrzeby homed, mają być nowym, uogólnionym nośnikiem informacji na temat użytkowników, pozwalając na odeseparowanie od warstwy uwierzytelniania oraz współpracę z systemd-logind. Pozwala to także "rozumieć" abstrakcyjnych użytkowników dynamicznych systemd na takich samych prawach, jak prawdziwi. Użytkownicy to koncepcja realizująca zbliżone potrzeby do tych pokrywanych przez Managed Service Accounts w systemie Windows. Oczywiście, aby całość działała, potrzebny jest też pam. Ściślej mówiąc pam_systemd, rzecz jasna.

Przy takiej architekturze zarządzania katalogami domowymi, system-logind może się wykazać jeszcze bardziej, nakładając odpowiednie limity zasobów dla użytkownika, wykraczające poza klasyczne quoty. A do narzędzi zarządzających dołącza nowy element, homectl. Poza tworzeniem i aktywacją katalogów domowych, oferuje on takie kwiatki, jak:

Jak go tu więc nie kochać. Baza użytkowników jest zarządzana przez userdb.service (wreszcie centralizacja!) oraz dedykowane polecenie userdbctl.

Systemd-homed ma pewną cechę charakterystyczną dla wielu komponentów systemd. Pozornie jest uniwersalny, zdradza nawet znamiona zastosowań "korporacyjnych" (w tym przypadku, centralizacja i łatwa współpraca z LDAP), ale okazuje się być mocno zorientowany dla użytkowników indywidualnych.

Systemy szyfrowane całościowo LUKSem raczej nie zaczną udawać bezstanowych z dnia na dzień i używać szyfrowania LUKSem samych katalogów domowych. Zresztą, jak się wtedy zalogować przez SSH? Katalog będzie zaszyfrowany, a klucz w środku! Takich pytań jest więcej.

Nowe rozwiązanie pojawi się w wersji 245 systemd i zapewne najpierw ujrzymy je w Fedorze. Jest ono póki co dość elementarne, ale na szczęście również całkowicie opcjonalne. Podobnie jak systemd-resolved i korzystanie z Linuksa na desktopie 😉

Z jednej strony, jest to interesujące rozwiązanie problemu, w którym klasyczny Uɴɪx wcale nie skaluje się tak ładnie, jak byśmy chcieli. Porządkuje szereg warstw abstrakcji i równoległych, kompletnie odmiennych metod zarządzania tożsamością, przypominając że zarządzanie tożsamością to nie do samo, co zarządzanie danymi. Z drugiej jednak strony, jest to oddzielna usługa do obsługi katalogów domowych!