Typowe problemy

Wstęp

Sednem sprawy systemu package user jest instalacja oprogramowania. Ponieważ skrypty instalacyjne są często pisane w założeniu, że będą uruchamiana z konta root-a czasami pojawiają się błędy gdy są uruchamiane z konta użytkownika pakietu. Jeśli ta przeszkoda zostanie pokonana i pakiet jest zainstalowany zazwyczaj nie ma żadnej różnicy pomiędzy instalacją z konta root-a. Kilka programów nalega by pewne wrażliwe z punktu widzenia bezpieczeństwa pliki były własnością roota i w innym przypadku nie uruchamiają się. Jest to jednak rzadka sytuacja. Poniżej znajduje się opis kilku mniej lub bardziej typowych problemów, które możesz napotkać instalując pakiety za pomocą metody package users, wraz z podpowiedziami jak je rozwiązać. Zostało to juz powiedziane wcześniej ale warto przypomnieć: wiele problemów, które spotkasz podczas instalacji tą metodą są porządanym zachowaniem. Lepiej spotkać się z błędem podczas instalacji niż pozwolić aby przeszła bez błędu ale z potencjalnym, niebezpiecznym działaniem z konta root-a bez twojej wiedzy.

Ogólna procedura

Gdy instalacja się nie powiedzie przyczyną jest prawie zawsze błąd „Permission denied” lub „Operation not permitted” po wydaniu polecenia ‚make install’. Pierwszą rzeczą do zrobienia jest zidentyfikowanie polecenia powodującego problem. Zazwyczaj widać to w wyjściu polecenia ‚make’ zaraz przed komunikatem błędu. Gdy już zidentyfikowałeś sprawcę musisz zdecydować czy podejmowana przez niego akcja jest niedozwolona, częściowo niedozwolona lub dozwolona. Niedozwolone polecenia mogą być po prostu usunięte z Makefile. Pozostałe dwie opcje są trudniejsze do obsłużenia. Musisz albo zmienić stan powodujący, że polecenie się nie wykonuje lub zmienić lub usunąć polecenie dokonując odpowiednich notatek, jeśli to spowoduje nie wykonanie porządanej czynności.

Później gdy już dokonałeś zmian wracasz do procesu instalacji i rozwiązujesz pozostałe pojawiające się problemy aż instalacja skończy się sukcesem. W tym momencie należy wykonać wszystkie pominięte, pozostałe czynności, które zostały wyłączone wcześniej. Na przykład ustawienie bitu setuid root dla pewnych plików.

Zauważ, że często Makefile jest generowane w procesie konfiguracji, czasami później w trakcie już samej budowy. Jeśli chcesz nanieść zmiany przed etapem konfiguracji zazwyczaj musisz wyedytować plik Makefile.in.

Zmiany uprawnień

Niektóre niewymyślne systemy budowania nie używają skryptów mkinstalldirs do tworzenia docelowych katalogów instalacyjnych i są bardzo źle napisane. Zamiast sprawdzić, czy docelowy katalog istnieje po prostu przystępują do tworzenia go z domyślnymi uprawnieniami. Problem ten objaiwa się zazwyczaj w linii typu „install -d $(prefix)/bin” w Makefile. W tym przypadku gdy prefix=/usr nastąpi próba utworzenia katalogu /usr/bin. Jeśli docelowy katalog już istnieje, instalacja będzie próbowała zmienić jego uprawnienia do domyślnych (lub takich jak w wpisane w linii poleceń). Oczywiście użytkownik pakietu nie jest uprawniony do zmiany uprawnień /usr/bin więc polecenie zakończy się niepowodzeniem z komunikatem w rodzaju: „install: cannot change permissions of `/usr/bin’: Operation not permitted”. To jest przykład absolutnie niedozwolonego polecenia. Po prostu usuń je z Makefile i będzie porządek.

Zmiany właściciela

Bardzo powszechną sytuacją gdy pakiet chce zmienić właściciela pliku podczas instalacji jest sytuacja instalacja plików z ustawionym setuid root. Polecenie wygląda podobnie do tego: „install -c -m 4755 -o root name /usr/bin/name” a błąd mniej więcej tak: „install: cannot change ownership of `name’: Operation not permitted” Zmiana właściciela na root jest ukryta w przełączniku „-o root” mówiącym, że docelowy plik ma mieć właściciela root. Czy w ogóle chcesz, żeby to miało miejsce to inna sprawa. Fakt, że zwykle ten plik jest instalowany z setuid nie znaczy, że też tak powinieneś instalować. Musisz sobie odpowiedzieć, czy zwykłemu użytkownikowi jest niezbędne uruchamianie tego pliku. Jeśli uznasz, że może on żyć bez tego możesz nie ustawiać setuid na tym pliku. Byłaby to tylko potencjalna dziura w bezpieczeństwie. W każdym przypadku powinieneś edytować Makefile i usunąć przestępczy przełącznik, „-o root” w tym przypadku i wtedy instalacja przejdzie bez problemu. Zauważ, że w tym przypadku plik będzie zainstalowany z setuid , co z oczywistych względów jest bez sensu. Jeśli w ogóle nie zamierzasz ustawiać setuid root po instalacji najlepiej zmienić również „-m 4755” na „-m 755”.

Wskazówka:
Gdy ustawiasz setuid root po instalacji używaj polecenia ‚chown root /usr/bin/name’ a nie ‚chown root:root /usr/bin/name’. W ten sposób zachowasz oryginalną grupę pliku (np. grupę użytkownika pakietu). Dodatkowo po zmianie właściciela wydaj polecenie ‚chmod u+s /usr/bin/name’.

Zapis do katalogu bez uprawnień

Czasami pakiety chcą utworzyć pliki lub katalogi w katalogach, do których grupa install nie ma uprawnień. Wchodzą tu w grę trzy możliwe sytuacje. Pierwsza możliwość jest taka, że docelowy katalog powinien być katalogiem instalacyjnym. Przykładowo /usr/share/aclocal. Ten katalog nie należy do standardowego systemu katalogów utworzonych podczas budowy systemu LFS. Jest tworzony przez pierwszy pakiet który ma potrzebę wrzucenia tam swoich plików i w związku z tym będzie własnością tego własnie użytkownika pakietu. Następny pakiet, który będzie próbował coś zapisać w tym katalogu spotka się z odmową dostępu. Rozwiązanie jest proste. Trzeba zmienić uprawnienia tego katalogu tak, by każdy mógłw do niego zapisywac (lub np. tylko grupa install, do której należą wszyscy package users). Nie trzeba tego robić z konta root, moze to zrobić wużytkownik pakietu, który jest właścicielem.

Druga możliwa przyczyna prób zapisów do katalogów bez uprawnień jest tylko częściowo uprawniona. Przykładowo chcesz zainstalować wszystko w innej, wskazanej lokalizacji. Niektóre pakiety instalują pliki nie przeznaczone do bezpośredniego uruchamiania w domyślnej lokalizacji libexec. W przypadku, gdy ustawimy prefix na prefix=/usr pakiet będzie próbował instalować swoje pliki do /usr/libexec a ponieważ nie istnieje, najpierw utworzyć ten katalog. W tego typu przypadku często nie trzeba zmieniać nic w Makefile. Wystarczy użyć przełącznika ‚make libexecdir=/usr/lib install’.

W trzecim przypadku pakiet chce zainstalować coś, czego nie powinien w ogóle instalować i nie chcesz, żeby to instalował. Można edytować Makefile i usunąć odpowiedzialne za to wpisy. Jednak wyszukiwanie wszystkich tego typu wpisów może się okazać dość kłopotliwe. Rozwiązaniem może być podobnie jak w drugim przypadku zmiana przełącznika np. na /foobar gdzie jest katalogiem w którym jest uruchamianane polecenie budowania. Czyli np. katalog rozpakowanych źródeł. To spowoduje, że pakiet utworzy niechciane katalogi bez żadnych problemów z uprawnieniami w katalogu foobar. Później można je skasować.

Usuwanie lub nadpisywanie plików.

W doskonałym świecie jeden pakiet nie powinien grzebać w plikach innego pakietu ale w świecie rzeczywistym takie konflikty od czasu do czasu się zdarzają. Podczas gdy admin instalujący jako root nie jest powiadamiany o tego typu sytuacjach i dowiaduje się o nich gdy jest już za późno, admin korzystający z systemu package users musi ten konflikt jakoś rozwiązać. Gdy pakiet spróbuje nadpisac lub skasować plik lub katalog należący do innego użytkownika dostanie odmowę dostępu. Nawet w katalogach w kórych ma prawo do zapisu ale z ustawionym bitem sticky. Chociaż czasami ciężko to zaimplementować rozwiązaniem tego typu problemów jest albo zmiana nazwy, usunięcie starszych pliów i katalogów przed instalacją albo zapobieżenie instalacji nowych plików, katalogów. Zapobiegane instalacji poszczególnych plików jest czasami bardzo łatwe. Jeśli znajdziesz linię w rodzaju „PROGRAMS=foo bar fubar barfu” w Makefile i „foo” jest nazwą konfliktowego pliku spróbuj go wyrzucić z tej listy. To powinno być wystarczające by nie był instalowany.

/sbin/ldconfig

Pakiety, które instalują biblioteki czasami uruchamiają /sbin/ldconfig jako część swojej instalacji zapewniającej, że dynamiczne biblioteki są poprawnie zarejestrowane w systemie. Ponieważ użytkownik pakietu nie jest uprawniony do nadpisywania /etc/ld.so.cache ldconfig kończy się niepowodzeniem. Ten komunikat błędu jest zwykle ignorowany w Makefile ale powinieneś go odnotować gdyż powinieneś po instalacji uruchomić ldconfig jako root.