Informacje ogólne

Podstawową ideę tego systemu można łatwo wyjaśnić. Każdy pakiet należy do pewnego ‚użytkownika pakietu’. Gdy instalujesz pakiet, budujesz i instalujesz go jako użytownik pakietu. Sprawia to, że wszystkie zainstalowane pliki stanowią własność użytkownika pakietu. W konsekwencji wszystkie zwyczajowe zadania związane z zarządzaniem mogą być wygodnie zrealizowane za pomocą standardowych narzędzi wiersza poleceń. Na przykład proste ‚ls -l ‚ powie ci do jakiego pakietu należy a ‚find -user …’ pozwoli na znalezienie wszystkich plików należących do odpowiedniego pakietu i przeprowadzenie na nich operacji usuwania, czyli odinstalowania pakietu.

Zarządzanie pakietami nie jest wszystkim do czego przydaje się ta metoda. Ponieważ użytkownicy pakietów nie mają uprawnień root-a instalacja pakietu jest ograniczona tym, do czego mają prawa. Jedną z niedozwolonych rzeczy jest na przykład nadpisywanie plików zainstalowanych przez innego użytkownika pakietu. Starcia pomiędzy różnymi pakietami, które chcą instalować pliki binarne, biblioteki lub pliki nagłówkowe o tych samych nazwach są częstsze niż mogłbyś przypuszczać. W tej metodzie nigdy nie grozi Ci sytuacja, w której instalacja pakietu B zniszczy po cichu pliki pakietu A bez poinformowania Cię o tym. Każda tego typu próba podczas instalacji pakietu B spowoduje błąd „Permission denied” lub „Operation not permitted” więc będziesz mieć szansę podjęcia odpowiednich kroków.

Kolejną rzeczą, której nie może zrobić użytkownika pakietu to instalacja plików z ustawionym setuid root. Decyzja do nadania tego typu uprawnień jest również czymś, czego ostrożny admin nie pozostawia w gestii twórcy pakietu.

Zazwyczaj konto użytkownika pakietu nie posiada poprawnego hasła więc tylko root może przelogować się za pomocą polecenia ‚su’ na to konto. To zapewnia, że użytkownicy pakietów nie otwierają dodatkowego wejścia do systemu i nie osłabiają bezpieczeństwa. Oczywiście *możesz* ustawić hasło aby umożliwić innym adminom instalacje i zarządzanie odpowiednimi pakietami bez udostępniania im konta roota. Mogą oni na przykład instalować, usuwać, zmieniać dodatkowe biblioteki, które mogą być potrzebne dla ich grup roboczych. W dalszym ciągu nie będą oni jednak mogli usuwać lub modyfikować bibliotek, które nie należą do nich, takich jak libc.