it-swarm-eu.dev

Existuje způsob, jak přestat psát „Sudo“ pro každou maličkost v Linuxu?

Budu dělat slušné množství PHP práce brzy, a mám zájem o učení RoR, tak jsem nainstaloval Linux Mint 12 ve svém VirtualBoxu.

Nejvíce frustrující aspekt přepínače se dosud týkal oprávnění pro Linux. Vypadá to, že nemohu udělat nic užitečného (jako například zkopírovat tarbal Symfony2 z mého adresáře Stahování do kořenového adresáře dokumentu a extrahovat ho), aniž bych se představoval jako root přes Sudo.

Existuje snadný způsob, jak říct linuxu, aby mi poskytl neomezený přístup k určitým adresářům, aniž by jednoduše vyhodil všechna svá povolení?

66

Mám na mysli dvě možnosti:

  1. Vlastní požadovaný adresář pomocí chown:

    Sudo chown your_username directory 
    

    (nahraďte své uživatelské jméno svým uživatelským jménem a adresář požadovaným adresářem.)

  2. Druhou věcí, kterou můžete udělat, je pracovat jako root tak dlouho, jak budete VÍTE, CO DĚLETE. Chcete-li použít root, postupujte takto:

    Sudo -s
    

    a pak můžete dělat cokoli, aniž byste museli před každým příkazem psát Sudo.

86
mtahmed

Obecně řečeno, vždy pracujte jako svůj vlastní uživatel, pokud neděláte něco, co má dopad na celý systém.

Pokud existují soubory, které chcete umístit na svůj webový server, pracujte jako svůj vlastní uživatel a poté pomocí Sudo přetáhněte soubory na místo v oblasti webového poskytování služeb vašeho souborového systému. Obvykle by to provedl instalační skript a spustili byste něco jako Sudo -u webmaster install-webserver-files, nebo lépe Sudo -u webmaster git update (nebo systém kontroly verze podle vašeho výběru).

Pokud pracujete na vývojovém serveru a chcete, aby vaše soubory byly okamžitě přístupné, vytvořte adresář v oblasti webového serveru a nechte si jej vlastnit nebo alespoň zapisovat. Po této jednorázové operaci (Sudo chown … nebo Sudo -u webmaster setfacl …), nebudete potřebovat zvýšená oprávnění pro každodenní provoz.

Někdy je vhodné umožnit více uživatelům zapisovat do adresáře nebo jinak mít různá oprávnění pro několik uživatelů jiných než vlastník nebo pro více skupin. Seznamy řízení přístup vám tuto schopnost poskytují. Viz Problémy s oprávněními pro sdílený adresář na server nebo Problém s oprávněním záložního skript .

Vždy to byla moje ideologie, že jako uživatel můžete dělat cokoli chcete na Linuxu a pro všechno ostatní, vždy existuje Sudo. Sudo umožňuje provádět několik věcí jako někteří jiní uživatelé, nejčastěji jako root pro správu systému. Sudo byl větší výhodný zdroj pro delegování některých mých rutinních úkolů a oprávnění jako (root) uživatel na jiné a pomohl mi spravovat můj čas a jiné časy lépe, aniž by se práva zvyšovala nad rámec toho, co je vyžadováno. Zároveň je to moje důvěra v ně, kdo udržuje jejich záznamy v konfiguračním souboru sudoers. Nejsem si jistý, zda by to mohlo souviset, ale co mohu říci je, že, Sudo vám dává lepší bezpečnostní perspektivu o tom, kdo všichni a co mohou dělat se svými důvěryhodnými oprávněními. I když se něco pokazí, nesou odpovědnost. (Vždy mohu udělat nějaké záludné peaky s informacemi o sudoers logech, abych našel viníky také). Moji kluci mi vždy vyjadřovali obavy, že musejí psát Sudo pro všechno, co chtěli dělat se zvýšenými oprávněními v prostředí Linuxu. Tady jsem také našel stejnou otázku.

Abych viděl řešení a hledal alternativy, narazil jsem Resource Based Access ControlsRBAC, ale v jiné dobrodružné zemi Solaris s nástroji jako - pfexec atd. Tento přístup je lepší, protože by to zachovalo privilegia uživatelů již zvýšená a věřilo by svědomí a bdělosti toho, co by sysadminové chtěli dělat s jejich oprávněními.

S ohledem na dostupná řešení RBAC a jejich implementace ve světě Linuxu jsem narazil

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

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

a přestože existují i ​​jiné implementace, považoval bych je za nejlepší v seznamu. Implementace RBAC je v organizaci spousta práce, zejména když je mnoho uživatelů. RBAC by znělo v homogenních prostředích s větším řešením. Pokud však v síti existují heterogenní instalace Unixu a uživatelská databáze je běžná, pak by to pravděpodobně selhalo. Protože SELinux není škálovatelný/implementovaný v systému Solaris a nástroje RBAC/pfexec nejsou implementovány v systému Linux. Existují různé přístupy k provedení jediné věci. Například: http://blogs.Oracle.com/darren/entry/opensolaris_rbac_vs_Sudo_howto

Různá instalace v síti nemusí tento přístup podporovat (nicméně openrbac může být považován za běžný implementační přístup), protože sudoers je jediný přístup hostitele nebo není schopen centralizované konfigurace v síti/doméně. /etc/sudoers je třeba synchronizovat pokaždé, když dojde ke změně. Při provozování souboru sudoers však existuje požadavek na znalostní databázi, je nutné porozumět jazyku politiky konfigurace sudoers, aby nedocházelo k chybám a umožňovalo jakékoli granty. RBAC může nabídnout centralizovaný přístup do určité míry, zatímco bezpečnostní profily mohou být společné, přidání/odebrání uživatele z přidělené role lze provést z jednoho místa (to je místo, kde jsou informace o uživateli/passwd/skupině uloženy pro doména jako LDAP, NIS nebo AD). To by také implicitně vyžadovalo pochopení příkazů požadovaných pro provoz v databázi RBAC, jako je smexec, smmultiuser, málo.

Sudo zde může nabídnout více napříč platformami, přestože funguje na všech unixových/podobných platformách, které nabízejí funkce setuid. Jak Sudo, tak RBAC se daří uživatelům bez oprávnění root dát některá oprávnění, která lze provést, aniž by bylo třeba zadat samotné heslo root. Sudo může poskytnout argumenty příkazového řádku, které mohou být použity při spouštění příkazů, jemnější/granulárnější přístup a čistě omezit na to, jaký příkaz s argumenty lze spustit se zvýšenými oprávněními. Zatímco RBAC může omezit použití až na nainstalované příkazy nebo binární soubory, ale nemá kontrolu nad argumenty příkazového řádku. Auditování je mnohem lepší a vestavěné v prostředí RBAC, zatímco Sudo, záleží na konfiguraci a také na přijatých bezpečnostních omezeních (jako neudělení Shell a zejména hostitelé mají povoleno přihlásit se k ostatním hostitelům bez jakéhokoli problémy). To jsou jen některé z rozdílů, které bych mohl citovat, a já osobně mám sklon používat Sudo než RBAC, i když s uvedenými omezeními bych mohl přijít implementovat některá pracovní místa. Dokud nebudou všechny problémy vyřešeny RBACem, aby se zlepšila výhoda Suda, nemyslím si, že Sudo odejde, protože je to jednoduché.

3
Nikhil Mulley

Ano, přihlaste se jako root, což vám dává super kontrolu přístupu uživatelů.
Stejný koncept v systému Windows, můžete se přihlásit ke svému terminálu pomocí správce.

3
ajreal

Chtěl bych podtrhnout kořen dokumentu, ve kterém pracujete, takže k němu máte plný přístup.

Chcete-li se vyhnout nutnosti psát Sudo při každé instalaci drahokamu, postupujte podle tohoto článku zde: http://forums.site5.com/showthread.php?t=11954

Doporučuji také nainstalovat RVM pro správu verzí Ruby a Rails. http://beginrescueend.com/

Usnadní vám život, když najdete hostitele, kterého chcete implementovat do různých verzí, než ve kterých jste se vyvinuli.

1
Catharz

Upravte soubor/etc/passwd a udělte rootovi uživatelská práva „yourUserName“ změnou ID uživatelů a skupin na UID 0 a GID 0:

yourUserName: 0: 0 ::/home/yourUserName:/bin/sh

0
Ufuk özkanlı

Jak je uvedeno v jiných odpovědích, nejčistším řešením je změna vlastnictví souborů a adresářů, ke kterým potřebujete přístup. Můžete také vytvořit novou vyhrazenou skupinu, změnit vlastnictví souborů a adresářů této skupiny a nastavit oprávnění pro zápis těchto souborů a adresářů do skupiny. Nakonec nastavte bit SGID v adresářích tak, že pokud vytvoříte nový soubor, zdědí vlastnictví skupiny obsahující adresář (tj. Vyhrazená skupina).

0
countermode

Spusťte příkaz.

Sudo su root

Nyní budete moci spouštět příkazy jako uživatel root. Buď opatrný! Jakýkoli spuštěný příkaz bude jako uživatel root. Pokud si nejste opatrní, můžete věci vážně zkazit.

Nebo změníte oprávnění adresáře, aby uživatel mohl ukládat a upravovat soubory.

0
Sbossb