Jeszcze jedna alternatywa pochodzi ze wskazówek Linux From Scratch :
Większa kontrola i zarządzanie pakietami za pomocą użytkowników pakietów
3 Użytkownicy pakietu
3.1 Wprowadzenie
Podstawową ideę tego schematu można łatwo wyjaśnić. Każdy pakiet należy do określonego „użytkownika pakietu”. Podczas instalowania pakietu kompiluje się i instaluje pakiet jako ten użytkownik pakietu, powodując, że wszystkie zainstalowane pliki są własnością użytkownika pakietu. W rezultacie wszystkie zwykłe zadania zarządzania pakietami można wygodnie realizować za pomocą standardowych narzędzi wiersza poleceń. Proste ls -l <file>powie ci na przykład, do którego pakietu
<file>należy, a find -user ...polecenie pozwala wykonać operację na wszystkich plikach należących do określonego pakietu, np. Usunąć je, aby odinstalować pakiet.
Jednak zarządzanie pakietami to nie wszystko, co jest dobre dla użytkowników pakietu. Ponieważ użytkownicy pakietu nie mają praw root, instalacja pakietu jest ograniczona pod względem możliwości. Jedną rzeczą, której użytkownik pakietu nie może na przykład zrobić, jest zastąpienie plików innym użytkownikiem pakietu. Konflikty między różnymi pakietami, które chcą zainstalować plik binarny, bibliotekę lub plik nagłówka o tej samej nazwie, są bardziej powszechne niż mogłoby się wydawać. W przypadku użytkowników pakietu nigdy nie ryzykujesz, że instalacja pakietu B zniszczy pliki z pakietu A w ciszy, bez zauważenia. Każda próba zrobienia tego podczas instalacji pakietu B spowoduje błąd „Odmowa zezwolenia” lub „Operacja niedozwolona”, dzięki czemu masz szansę podjąć odpowiednie kroki. Inną rzeczą, której użytkownicy pakietu nie mogą robić, jest instalowanie plików binarnych root setuid. Decyzja o utworzeniu binarnego katalogu głównego setuid jest również czymś, czego rozsądny administrator nie chce pozostawić twórcy pakietu oprogramowania.
Zwykle konta użytkowników pakietów nie mają prawidłowego hasła, więc tylko użytkownik root może su
dla użytkownika pakietu, co zapewnia, że użytkownicy pakietu nie otworzą dodatkowej drogi do systemu i podważą bezpieczeństwo. Ale i tak możesz ustawić hasła, aby zezwolić współadministratorowi, który chcesz mieć możliwość zainstalowania i zarządzania niektórymi pakietami oprogramowania, bez dostępu do faktycznego konta root. Ten współadministrator może na przykład instalować, usuwać, zmieniać dodatkowe biblioteki, które mogą być konieczne dla jego grupy roboczej. Nie byłby jednak w stanie usunąć ani zmodyfikować bibliotek, które do niego nie należą, takich jak libc.
Po tej pierwszej prymitywnej sugestii znalazłem rozwinięty wariant:
crablfs - oparty na użytkownikach system zarządzania pakietami
To crablfsnajnowszy przykład zarządzania pakietami przy użyciu unikatowych identyfikatorów UID i GID do zarządzania pakietami, ale na sourceforge ponownie ewoluuje w ulfs:
uLFS: Twój zarządzalny i wielokrotnego użytku Linux od zera
Dla przyczynowych użytkowników zainstalowanych pakietów myślę, że rozwiązanie LFS dla „użytkowników pakietów” jest lekkie, mniej inwazyjne i eleganckie. W skrócie, zainstalować pakiety w /usr/locallub /home/user/locali zapisuje pliki przy użyciu unikalnych identyfikatorów UID i GID dla każdego pakietu, ale umieścić wszystkie pliki w tradycyjnych miejscach, wspólnych katalogów /usr/local/bin, /usr/local/libjak to jest we wszystkich dystrybucjach Linuksa nurtu ... niedrożność plik i niechciany plik nadpisywania lub usuwanie unika go zgrabna sztuczka na Linuksa wyjaśniona przez Matthiasa S. Benkmanna w more_control_and_pkg_man.txt, która wymaga tylko normalnej manipulacji uprawnieniami do plików i katalogów, na przykład lepkich uprawnień do katalogów, aby uniknąć niechcianych nadpisań plików:
3.3 Grupy
Każdy użytkownik pakietu należy do co najmniej 2 grup. Jedną z tych grup jest grupa „instaluj”, do której należą wszyscy użytkownicy pakietu (i tylko użytkownicy pakietu). Wszystkie katalogi, w których pakiety mogą instalować rzeczy, należą do grupy instalacyjnej. Obejmuje to katalogi takie jak / bin i / usr / bin, ale wyklucza katalogi takie jak / root lub /. Katalogi należące do grupy instalacji zawsze można zapisać w grupie. Byłoby to wystarczające dla aspektów zarządzania pakietami, ale bez dalszego przygotowania nie zapewniłoby to dodatkowego bezpieczeństwa ani kontroli, ponieważ każdy pakiet mógłby zastąpić pliki z innego pakietu (zmiana byłaby widoczna w danych wyjściowych zls -l, chociaż). Z tego powodu wszystkie katalogi instalacyjne otrzymują atrybut sticky. Pozwala to użytkownikom tworzyć nowe pliki oraz usuwać lub modyfikować własne pliki w katalogu, ale plików innych użytkowników nie można modyfikować ani usuwać. W pozostałej części tej podpowiedzi, ilekroć użyty zostanie termin „katalog instalacyjny”, odnosi się on do katalogu należącego do instalacji grupowej, zapisywalny w grupie i lepki. IOW, aby zmienić się <dir>w katalog instalacyjny
chgrp install && chmod g + w, o + t
Dla mnie wygląda to na proste i sprytne rozwiązanie! Użyłem tego schematu w mojej kompilacji LFS i jest to działające rozwiązanie ...