Czy bezpiecznie jest chown `/ usr / local`?

Wiem do czego /usr/localsłuży - instalacja oprogramowania na maszynie lokalnej. Domyślnie rootjest właścicielem katalogu. Oznacza to, że aby zainstalować tam, musisz użyć sudo. W przypadku komputera dla jednego użytkownika lub dewelopera wydaje się to niepotrzebnym dodatkowym użyciem polecenia. Stąd moje pytanie - czy posiadanie jest dla mnie bezpieczne /usr/local?

Na przykład Homebrew dla OS X „Po prostu działa”, ponieważ jest właścicielem /usr/locali bezpiecznie instaluje tam swoje oprogramowanie bez użycia sudo.

Dodatkowo, jeśli masz zainstalowane lokalnie skompilowane oprogramowanie /usr/local, oprogramowanie potrzebuje obecnie roota, aby się zmodyfikować lub zainstalować wtyczki. Wydaje się to niebezpieczne - chcę używać tylko sudowtedy, gdy DOKŁADNIE wiem, co się stanie.

Opinie?

Nie mogę polecić zostania właścicielem /usr/local; w większości sytuacji jest to prawdopodobnie mniej bezpieczne niż używanie sudo.

Twoje pytanie sugeruje dwa powody, dla których możesz chcieć chown /usr/local.

Pierwszym jest uniknięcie konieczności sudoinstalowania oprogramowania. Dla niektórych (np. Autora tej odpowiedzi ) może to oznaczać , że chcesz pracować wydajnie, lub zapisać naciśnięcia klawiszy potrzebne do sudowpisania i wprowadzenia hasła. Ale prawdopodobnie, kiedy mówisz „niepotrzebne”, powołujesz się na zasadę najmniejszego przywileju :

Domyślnie rootjest właścicielem katalogu. Oznacza to, że aby zainstalować tam, musisz użyć sudo. W przypadku komputera dla jednego użytkownika lub dewelopera wydaje się to niepotrzebnym dodatkowym użyciem polecenia

Dość często słyszę / czytam ludzi opiniotwórczych / narzekających w stylu: „Tylko ja korzystam z tego systemu, więc nie powinienem używać sudoi wprowadzać hasła”. Dla czytelników, którzy mają taki pogląd i ponieważ jest on istotny w tym miejscu, przypomnijmy sobie podstawowy powód bezpieczeństwa dla rootowania własnymi rzeczami.

Większość plików programów zainstalowanych w systemie Ubuntu ma tryb plików 755 lub zapisany symbolicznie rwxr-xr-x, co oznacza, że każdy użytkownik lub program może je wykonać , ale tylko właściciel plików, root, może je zmodyfikować. (Technicznie wymaga to również, aby nikt poza rootem nie miał wuprawnień do katalogu, który je zawiera, aby inni użytkownicy nie mogli ich usunąć ani przenieść).

Oznacza to, że skromny użytkownik może uruchomić dowolny program. Jeśli spróbujesz użyć programu do zrobienia czegoś, do czego nie masz uprawnień, na przykład do wykonania operacji zapisu na pliku należącym do roota, spowoduje to błąd. Powoduje to, że literówka w niektórych poleceniach, błędnej aplikacji lub złośliwym kodzie jest mniej prawdopodobne, aby zepsuć twój system - chyba że działa jako root, nie będzie miał na to pozwolenia. Jest to szczególnie przydatne podczas uruchamiania programów, które wchodzą w interakcje z Internetem.

Jeśli ty chown /usr/local, dowolny program działający z twoimi uprawnieniami może tam zapisać pliki, które z jakiegoś powodu mogą zostać później wykonane jako root, na przykład poprzez zastąpienie innego polecenia o tej samej nazwie. /usr/local/binjest domyślnie $PATH, a sudo„s secure_path, a to przychodzi przed innych miejscach w obu. Więc jeśli mam dwa pliki wykonywalne

/usr/local/bin/chown
/bin/chown

kiedy wykonać sudo chown ..., w zostanie wykonany .chown/usr/local/bin

Ale prawdopodobnie już to wszystko wiedziałeś, ponieważ twoim drugim powodem jest bezpieczeństwo:

Dodatkowo, jeśli masz zainstalowane lokalnie skompilowane oprogramowanie /usr/local, oprogramowanie potrzebuje obecnie roota, aby się zmodyfikować lub zainstalować wtyczki. Wydaje się to niebezpieczne - chcę używać tylko sudowtedy, gdy DOKŁADNIE wiem, co się stanie.

_{Na wszelki wypadek, gdy trzeba o tym wspomnieć, absolutnie słuszne jest (zgodnie z FHS), aby zainstalować lokalnie skompilowane oprogramowanie /usr/local, ale sama kompilacja powinna odbywać się gdzieś w twoim $HOME, bez sudo, aż do ostatniego kroku, kiedy piszesz sudo make installlub odpowiadasz.}

Myślę, że sugerujesz, że uruchamiając program zainstalowany /usr/localjako nieuprzywilejowany właściciel, możesz użyć określonych błędów uprawnień zgłaszanych podczas próby samodzielnej aktualizacji, aby zobaczyć, że próbuje zmodyfikować inną lokalizację systemu plików, która nie jest twoją własnością w sposób nie chcę, żebyś mógł to powstrzymać.

To może być pomocne. Implikacja polega na tym, że ufasz programowi, że robi wszystko, co mu się podoba /usr/local, ale nie gdzie indziej. Jeśli żąda podniesionych uprawnień, możesz odmówić zezwolenia na aktualizację lub odinstalować. To ma dla mnie sens. Ale myślę, że próba użycia /usr/localtego rodzaju jako piaskownicy w ten sposób prawdopodobnie nie jest dobrym pomysłem, a przynajmniej nie jest najbezpieczniejszym rozwiązaniem. To nie jest właściwie izolowana lokalizacja ( /optjest trochę bardziej izolowana, ponieważ nie ma jej w ustawieniach domyślnych $PATH). Program może zapisać lub usunąć coś, co /usr/localmoże spowodować uszkodzenie. Inne (potencjalnie źle napisane) programy, które uruchamiasz, mogą tam pisać i wykonywać kod, o którym nie wiesz.

Jeśli obawiasz się, że pozwolisz programowi na bezpieczną aktualizację, prawdopodobnie powinieneś poszukać alternatywnych rozwiązań (być może specyficznych dla programu, jak na przykład w Pythonie, lub możesz poszukać przystawki lub podobnej implementacji, która odpowiada Twoim potrzebom, lub użyć kontenery lub maszyna wirtualna do testowania potencjalnie niebezpiecznego oprogramowania) przed ujawnieniem lokalizacji systemu (nawet względnie użytkownika) do zapisania przez programy uruchomione przez zwykłego użytkownika. Wydaje mi się, że może to mieć nieprzewidywalne skutki, ponieważ pozwala programom tymczasowo podwyższać uprawnienia sudo.

To niezwykłe, że /usr/localnie jest własnością root. Ale możesz zmienić właściciela, jak chcesz.

Ale radzę upewnić się, że /usr/local/sbinnadal jest własnością, rootaby uniknąć problemu z bezpieczeństwem. Polecenia tutaj są zwykle wywoływane tylko przez root.

W przypadku oprogramowania, którego potrzebujesz, użyj katalogu domowego zamiast /usr/local.

Zamiast zmieniać własność /usr/locallub uruchamiać polecenia jako root, gdy nie chcesz, powinieneś po prostu skonfigurować swoje kompilacje, aby instalowały się w twoim katalogu domowym zamiast /usr/local. Rozwiązuje to wszystkie potencjalne problemy ze zmianą własności /usr/local, w tym sposób, w jaki jej bini sbinpodkatalogi są na rootdrodze.

Jeśli musisz zezwolić innym użytkownikom na uruchamianie twojego oprogramowania, możesz dać im dostęp. W rzeczywistości prawdopodobnie będą już w stanie to zrobić, ponieważ domyślnie twój katalog domowy ma dozwolony dostęp do odczytu i wykonywania . (Jeśli tego nie chcesz, możesz to dość łatwo zmienić, po prostu używając chmoddowolnych plików lub katalogów, które chcesz ustawić jako prywatne, i ewentualnie również zmieniając swój umask.)

Po zainstalowaniu oprogramowania w katalogu domowym, pliki binarne, które zostałyby wprowadzone, /usr/local/binwejdą zamiast niego . Otrzymasz inne podkatalogi swojego katalogu domowego odpowiadające podkatalogom tego , którego potrzebuje zainstalowane oprogramowanie. Zwykle dzieje się to automatycznie po zainstalowaniu oprogramowania z kodu źródłowego./home/username/bin/usr/local

Konfigurowanie twoich kompilacji

Większość oprogramowania tworzonego z kodu źródłowego ma jeden etap:

./configure

W zdecydowanej większości oprogramowania dostarczanego ze configureskryptem, który można uruchomić w ten sposób, domyślnie konfiguruje się kompilację do instalacji wewnątrz, /usr/localgdy w końcu uruchomisz ją, sudo make installaby ją zainstalować. Powodem jest to, że jest to domyślnie równoważne z uruchomieniem:

./configure --prefix=/usr/local

Aby skonfigurować kompilację do instalacji w katalogu domowym, użyj tego zamiast:

./configure --prefix="$HOME"

W praktyce w Ubuntu ścieżki do katalogu domowego nie zawierają spacji, innych białych znaków ani innych znaków, które będą traktowane specjalnie przez powłokę, np. *Chyba że skonfigurujesz konto użytkownika dość dziwnie, możesz po prostu wpisać:

./configure --prefix=$HOME

(Nie polecam jednak przyzwyczaić się do pisania skryptów . Ponadto w niektórych innych systemach operacyjnych - takich jak macOS - rzadziej ścieżki do katalogów domowych użytkowników zawierają spacje).

Lub jeśli wolisz, możesz wpisać pełną ścieżkę do katalogu domowego:

./configure --prefix=/home/username

( usernameOczywiście zamień na swoją rzeczywistą nazwę użytkownika. Jeśli z jakiegoś powodu twojego katalogu domowego nie /homema, będziesz musiał odpowiednio dostosować.)

Instalowanie twoich kompilacji

Po uruchomieniu makemożesz być przyzwyczajony do uruchamiania sudo make install, ale podczas instalacji we własnym katalogu domowym nie musisz uruchamiać go jako root, więc możesz - i powinieneś - usiąść sudo. Po prostu biegnij:

make install

Podobnie w przypadku oprogramowania obsługującego uninstallcel:

make uninstall

Właśnie o to prosiłeś ... nie w twoim katalogu domowym /usr/local.

Uruchamianie programów

Prawdopodobniebin podkatalogu katalogu domowym jest:

• już w swojej $PATH, lub
• będzie w twoim, $PATHjeśli wylogujesz się i wrócisz.

Powodem jest to, że .profileplik w katalogu domowym, który zawiera polecenia uruchamiane podczas logowania, zawiera go domyślnie dla kont użytkowników utworzonych w większości wersji Ubuntu (w tym początkowego konta administratora utworzonego podczas instalacji systemu operacyjnego):

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi

Ten kod działa, gdy się logujesz (ponieważ jest .profile) i umieszcza Twój osobisty binkatalog $PATH tylko wtedy, gdy istnieje. Dlatego może być konieczne wylogowanie się i ponowne zalogowanie.

Starsze wersje, takie jak Ubuntu 14.04, a także nowsze wersje, takie jak Ubuntu 17.10, mają tę funkcję . Jednak Ubuntu 16.04, które jest prawdopodobnie najpopularniejszą wersją tego pisma, ma to zamiast tego:

# set PATH so it includes user's private bin directories
PATH="$HOME/bin:$HOME/.local/bin:$PATH"

To po prostu dodaje binpodkatalog twojego katalogu domowego ---, a także .local/binpodkatalog - do twojego $PATH, bez sprawdzania, czy te katalogi faktycznie istnieją. Jeśli więc korzystasz z wersji 16.04 lub zaktualizowałeś system z wersji 16.04, kiedy Twoje konto użytkownika zostało utworzone, wtedy binpodkatalog twojego katalogu domowego jest już prawdopodobnie w twoim katalogu $PATH.

Twój .profileplik jest kopiowany z /etc/skelkatalogu podczas tworzenia konta użytkownika. Jeśli twoje konto użytkownika zostało utworzone w starszej wersji Ubuntu, otrzymało tę wersję .profilei nie zostało zmienione - dla twojego konta użytkownika - przez uaktualnienie do nowszej wersji.

Gdy binpodkatalog twojego katalogu domowego będzie już w twoim $PATH, będziesz mógł uruchamiać programy, których pliki wykonywalne są tam instalowane, po prostu wpisując ich nazwy, tak jak w przypadku programów zainstalowanych przez menedżera pakietów Ubuntu lub zainstalowanych wewnątrz /usr/local.

.localOption

Być może zauważyłeś, że domyślny .profileplik dla kont użytkowników utworzonych w niektórych wersjach Ubuntu, w tym w 16.04, jak opisano powyżej, dodaje nie tylko $HOME/bintwojej ścieżce, ale także $HOME/.local/bin. Jeśli .profilenie dodajesz tego, ale chcesz , możesz to po prostu edytować.

Choć często używane do przechowywania ustawień i danych w pamięci podręcznej , można również zainstalować oprogramowanie w .localpodkatalogu katalogu domowego. Powinieneś czuć się nieskrępowany, ponieważ z punktu widzenia użyteczności i bezpieczeństwa --prefix="$HOME/.local"jest podobny --prefix="$HOME".

Pamiętaj, że pliki i katalogi, które zaczynają się od, .nie są domyślnie wyświetlane w graficznych przeglądarkach plików (użyj Ctrl+, Haby je odkryć i ukryć) lub w lspoleceniu (przekaż flagę -Alub, -aaby je pokazać). To może nie być to, czego chcesz lub może być dokładnie to, czego chcesz. Jest to kwestia osobistych preferencji.

Zauważyłem jednak, że niektóre zautomatyzowane menedżery pakietów oparte na źródłach, które budują i instalują oprogramowanie w swoim katalogu domowym $HOME/.local. Nie wiem, jak często to się dzieje - mam nadzieję, że zbadam dalej i zaktualizuję tę odpowiedź - ale możesz chcieć używać tylko $HOMEdo rzeczy, które kompilujesz ręcznie. W ten sposób będzie jasne, skąd się wzięły rzeczy. A jeśli dojdzie do kolizji, oprogramowanie nadal prawdopodobnie będzie akceptowalnie współistnieć.

Możesz również celowo zainstalować niektóre oprogramowanie $HOME/.locali inne oprogramowanie w $HOME. To zależy od Ciebie. Którykolwiek binkatalog pojawi się jako pierwszy w $PATHzmiennej środowiskowej, to ten, z którego uruchomione zostanie polecenie, w przypadku, gdy w obu występują polecenia o tej samej nazwie.

Podziękowania należą się Zanna i Videonauth za wskazanie błędów w poprzedniej wersji tej odpowiedzi, dotyczących tego, które wersje Ubuntu mają domyślny kod .profile, oraz pomoc w ich poprawieniu (patrz także tutaj ).

Jeśli sudo jest taką niedogodnością, po prostu zaktualizuj / etc / sudoers, abyś nie musiał wpisywać hasła podczas uruchamiania sudo. Uważam, że jest to lepsze rozwiązanie niż zmiana właściciela / usr / local.