Czy istnieje sposób, aby przestać pisać „sudo” dla każdej drobnej rzeczy w Linuksie?

Niedługo będę miał sporo pracy z PHP i jestem zainteresowany nauką RoR, więc zainstalowałem Linux Mint 12 w moim VirtualBoxie.

Do tej pory najbardziej frustrującym aspektem przełącznika było zajmowanie się uprawnieniami Linuksa. Wygląda na to, że nie mogę nic zrobić (na przykład skopiować archiwum Symfony2 z katalogu Pobrane do katalogu głównego dokumentu i wyodrębnić go) bez udawania roota za pomocą sudo.

Czy istnieje prosty sposób, aby powiedzieć linuxowi, aby zapewnił mi nieograniczony dostęp do niektórych katalogów, nie otwierając po prostu wszystkich swoich uprawnień?

Przychodzą mi na myśl dwie opcje:

1. Posiadaj katalog, który chcesz, używając chown:

   sudo chown your_username directory 
   

   (zamień swoją nazwę użytkownika na swoją nazwę użytkownika, a katalog na żądany katalog).

2. Inną rzeczą, którą możesz zrobić, to pracować tak długo, jak WIESZ, CO ROBISZ . Aby użyć roota:

   sudo -s
   

   i wtedy możesz zrobić wszystko bez konieczności pisania sudoprzed każdym poleceniem.

Ogólnie rzecz biorąc, zawsze pracuj jako własny użytkownik, chyba że robisz coś, co ma wpływ na cały system.

Jeśli istnieją pliki, które chcesz umieścić na swoim serwerze internetowym, pracuj jako własny użytkownik, a następnie użyj przycisku, sudoaby upuścić pliki na swoim miejscu w obszarze udostępniania w systemie plików. Zwykle wykonuje się to za pomocą skryptu instalacyjnego i uruchamiasz coś podobnego sudo -u webmaster install-webserver-fileslub lepszego sudo -u webmaster git update(lub wybrany system kontroli wersji).

Jeśli pracujesz na serwerze programistycznym i chcesz, aby Twoje pliki były natychmiast dostępne, utwórz katalog w obszarze serwera WWW i ustaw go jako własność lub przynajmniej do zapisu. Po tej jednorazowej operacji ( sudo chown …lub sudo -u webmaster setfacl …) nie będziesz potrzebować podwyższonych uprawnień do codziennych operacji.

Czasami wygodnie jest pozwolić wielu użytkownikom pisać w katalogu lub w inny sposób mieć różne uprawnienia dla kilku użytkowników innych niż właściciel lub dla wielu grup. Listy kontroli dostępu dają tę możliwość. Zobacz Problemy z uprawnieniami do współdzielonego katalogu na serwerze lub Problem z uprawnieniami do skryptu kopii zapasowej .

Tak, zaloguj się jako root, co daje ci super kontrolę dostępu użytkownika.
Ta sama koncepcja w systemie Windows, możesz zalogować się do terminala za pomocą administratora.

Zawsze moją ideologią było to, że jako użytkownik możesz robić w Linuksie wszystko, co chcesz, a do wszystkiego innego zawsze jest sudo. sudopozwala na wykonanie kilku rzeczy tak, jak niektórzy inni użytkownicy, najczęściej przypadki rootdotyczące administracji systemu. sudostanowi większą zaletę, ponieważ deleguję niektóre z moich rutynowych zadań i uprawnień jako użytkownik (root) innym użytkownikom i pomaga lepiej zarządzać moim czasem, a innym lepiej, bez zwiększania uprawnień do poziomu wykraczającego poza to, co jest wymagane. Jednocześnie moje zaufanie do nich utrzymuje ich wpisy wsudoersplik konfiguracyjny. Nie jestem pewien, czy można to powiązać, ale mogę powiedzieć, że sudo daje lepszą perspektywę bezpieczeństwa dla tego, kto i co mogą zrobić ze swoimi zaufanymi uprawnieniami. Nawet jeśli coś pójdzie nie tak, są odpowiedzialni. (Zawsze mogę zrobić coś podstępnego z logiem sudoers, aby znaleźć winowajców). Moi faceci zawsze wyrażali obawy, że muszą pisać sudo we wszystkim, co chcą robić z podwyższonymi uprawnieniami w środowisku Linux. Tutaj też znalazłem to samo pytanie.

Aby zobaczyć rozwiązania i moje poszukiwania alternatyw, natknąłem się na Kontrolę dostępu opartą na zasobach,RBAC ale w innej krainie przygód Solarisz narzędziami takimi jak pfexecitp. Takie podejście jest lepsze, ponieważ pozwoliłoby to zachować uprawnienia użytkowników już podniesione i zaufać na sumieniu i czujności tego, co sysadmini chcieliby zrobić ze swoimi przywilejami.

Biorąc pod uwagę dostępne rozwiązania RBAC i jego implementacje w świecie Linuksa, natknąłem się na to

SELinux http://www.ibm.com/developerworks/linux/library/l-rbac-selinux/

grsecurity http://en.wikipedia.org/wiki/Grsecurity

i chociaż istnieją inne implementacje, rozważę je w najwyższej kolejności na liście. Wdrożenie RBAC jest bardzo pracochłonne w organizacji, zwłaszcza gdy jest wielu użytkowników. RBAC wydaje się lepszym rozwiązaniem w jednorodnych środowiskach. Jeśli jednak w sieci występują heterogeniczne instalacje systemu Unix, a baza danych użytkowników jest wspólna, być może to się nie powiedzie. Ponieważ SELinux nie jest skalowalny / zaimplementowany w systemie Solaris, a narzędzia RBAC / pfexec nie są zaimplementowane w systemie Linux. Istnieją różne podejścia do robienia jednej rzeczy. Na przykład: http://blogs.oracle.com/darren/entry/opensolaris_rbac_vs_sudo_howto

Różne instalacje w sieci mogą nie obsługiwać tego podejścia (jednak openrbac można uznać za wspólne podejście do implementacji), tak jak sudoers jest podejściem z jednym hostem lub nie jest w stanie scentralizowanej konfiguracji w sieci / domenie./etc/sudoersmuszą być synchronizowane za każdym razem, gdy nastąpi zmiana. Ponadto podczas korzystania z pliku sudoers wymagana jest baza wiedzy. Konieczne jest zrozumienie języka strategii konfiguracji sudoers, aby nie popełniać błędów i nie zezwalać na żadne granty. RBAC może oferować do pewnego stopnia scentralizowane podejście, podczas gdy profile zabezpieczeń mogą być wspólne, dodawanie / usuwanie użytkownika z przyznanej roli można wykonać z jednego miejsca (to jest miejsca, w którym przechowywane są informacje o użytkowniku / passwd / grupie domena taka jak LDAP, NIS lub AD). Wymagałoby to również domyślnie zrozumienia poleceń wymaganych do działania na bazie danych RBAC, takich jak smexec, smmultiuser, ponieważ jest ich niewiele.

Sudo może zaoferować więcej podejścia międzyplatformowego, mimo że działa na wszystkich platformach typu Unix / podobnych, które oferują funkcje setuid. Zarówno sudoi RBACuda się dając użytkownikom innym niż root niektóre przywileje, które można zrobić z zewnątrz dając rootsamego hasła. Sudo może zastosować bardziej precyzyjne / bardziej szczegółowe podejście do argumentów wiersza poleceń, których można użyć podczas uruchamiania poleceń i ograniczyć wyłącznie do tego, które polecenie z argumentami można uruchomić z podwyższonymi uprawnieniami. Podczas gdy RBAC może ograniczać się do korzystania z zainstalowanych poleceń lub plików binarnych, ale nie może mieć żadnej kontroli nad argumentami wiersza poleceń. Audyt jest znacznie lepszy i jest wbudowany w środowisko RBAC, natomiastsudo, zależy to od konfiguracji, a także podjętych ograniczeń bezpieczeństwa (takich jak nieprzyznanie powłoki, a zwłaszcza hosty mogą bez problemu logować się na innych hostach). To tylko niektóre z różnic, które mógłbym zacytować, a ja osobiście mam skłonność do używania sudo niż RBAC, chociaż przy wspomnianych ograniczeniach mogłem niejednokrotnie wprowadzać różne rozwiązania. Dopóki wszystkie problemy nie zostaną rozwiązane przez RBAC dla lepszej korzyści sudo, nie sądzę, że sudo odejdzie, ponieważ jest to proste.

Przeglądałbym katalog główny dokumentu, w którym pracujesz, abyś miał do niego pełny dostęp.

Aby uniknąć konieczności wpisywania sudo za każdym razem, gdy instalujesz klejnot, postępuj zgodnie z tym artykułem tutaj: http://forums.site5.com/showthread.php?t=11954

Polecam również instalowanie RVM do zarządzania wersjami Ruby i Rails. http://beginrescueend.com/

Ułatwi ci to życie, gdy znajdziesz hosta, w którym chcesz wdrożyć aplikację, używając innych wersji niż ta, w której opracowałeś.

Uruchom polecenie.

sudo su root

Teraz będziesz mógł uruchamiać polecenia jako użytkownik root. Bądź ostrożny! Każde uruchomione polecenie będzie działało jako użytkownik root. Możesz poważnie zepsuć wszystko, jeśli nie będziesz ostrożny.

Lub zmienisz uprawnienia do katalogu, aby umożliwić użytkownikowi zapisywanie i edycję plików.

Edytuj plik / etc / passwd i nadaj uprawnienia root użytkownikowi „twojaNazwaUżytkownika”, zmieniając ID użytkownika i grupy na UID 0 i GID 0:

twojaNazwaUżytkownika: 0: 0 :: / home / twojaNazwaUżytkownika: / bin / sh

Jak wskazują inne odpowiedzi, najczystszym rozwiązaniem jest zmiana własności plików i katalogów, do których potrzebujesz dostępu. Możesz także utworzyć nową dedykowaną grupę, zmienić własność grupy plików i katalogów na tę grupę oraz ustawić uprawnienia do zapisu grupy dla tych plików i katalogów. Na koniec ustaw bit SGID w katalogach, aby po utworzeniu nowego pliku odziedziczył on własność grupy zawierającego katalog (tj. Grupę dedykowaną).

użytkownik @ serwer: ~ $ sudo hasło root
[sudo] dla użytkownika:
wprowadź nowe hasło UNIX : wpisz
ponownie nowe hasło UNIX:
hasło: hasło zostało pomyślnie zaktualizowane
użytkownik @ serwer: ~ $ su
Hasło:
root @ serwer: / home / użytkownik #

Czy to pytanie „#” nie jest rzeczą piękną?

Używam „sudo” tylko raz, aby osiągnąć umiejętność

użytkownik @ serwer: ~ $ su
Hasło:
root @ serwer: / home / użytkownik #

na całe życie serwera.

Aby znów było bezpieczne,

root @ server: / home / user # exit
exit
user @ server: ~ $

Sysadmini robili to od lat, kiedy „sudo” nie było częścią trendu mollycoddling.

Kiedy to robisz, Twoim obowiązkiem jest dbać, a nie moje.

Ian