Příspěvky

1411

Server / Re:Nelze vytvořit adresář v /srv běžným uživatelem

« kdy: 20. 02. 2019, 06:58:50 »

Chápu správně, že tedy nejlepší až moc přehnaně dokonalé řešení navrhuje @Miroslav Šilhavý , zatímco uživatel @Filip Jirsák doporučuje standardní řešení, které je z hlediska bezpečnosti v pořádku a zcela běžné.

Běžné určitě není, protože ACL je něco, co nemusíte mít k dispozici, co není zajištěno, že bude za všech okolností a na všech systémech a na všech filesystémech fungovat. Stačí chybně provedené kopírování nebo přesunutí dat a máte po ACL.

Moje řešení je dalek jednodušší na správu - jednou nastavíte a můžete na to zapomenout. Kdyby došlo k nějaké chybě, výsledkem bude odepření přístupu (nikdo se k datům nedostane).

Filipovo řešení má problém v tom, že může nastat několik situací, kdy selže, a výsledkem nebude odepření přístupu, ale naopak to, že se k datům dostane i někdo cizí. Výsledkem také může být to, že se někomu podaří Vám podstrčit script nebo data, které spustíte pod uživatelem postgres a tím shodíte celý databázový server.

Založit uživatele, založit roli v postgresu = odhadem dvě minuty práce? Toto je celé, co potřebujete udělat:

Kód: [Vybrat]

adduser --disabled-password pgmaint
chown pgmaint:pgmaint /srv
chmod 0750 /srv

su - posgres -c "createuser -s -P pgmaint"
echo "localhost:*:*:pgmaint:<heslo>" > ~pgmaint/.pgpass
chown pgmaint:pgmaint ~pgmaint/.pgpass
chmod 0600 ~pgmaint/.pgpass

Uživatel pgmaint pak bude moci zakládat v postgresu role, zakládat databáze, rušit je, dělat dumpy, natahovat dumpy. Ale neohrozí samotný proces posgresu, neohrozí datové soubory postgresu.

1412

Server / Re:DB - ako riesia indexy?

« kdy: 19. 02. 2019, 18:44:49 »

V rámci jednoho dotazu můžete mít více indexů nad různými tabulkami. Některé databáze umí, pro urychlení JOINu, jeden index pro více tabulek, ale to jsem tady nemyslel. Jak jsem psal - upřesňoval jsem situaci, kdy se v dotazu nad jednou tabulkou má aplikovat více indexů.

Mně Váš příspěvek vyzněl, jako kdyby měl být jeden index nad více tabulkami. V teorii si to dovedu představit (dvě tabulky a foreign key mezi nimi), v praxi měl ale nenapadlo nic jiného, než materialized view, proto jsem se ptal, jestli mi něco neuniklo.

1413

Software / Re:Nejasnosti ohledně suoders

« kdy: 19. 02. 2019, 17:03:41 »

Jsem rád, že se zde rozvíjí takáto diskuze.

Mohl by mi někdo prosím odpovědět na můj souhrn? Zda to chápu správně?

john ALL=(ALL) ALL

Dává možnost uživateli "john" vykonávat jakýkoliv příkaz, za jakéhokoliv uživatele (včetně roota). Jediné, na co bude tázán je heslo uživatele "john" (jen pro jistotu, jestli je "john" stále u klávesnice). Není vyžadováno heslo roota, není vyžadováno heslo žádného jiného uživatele.

Co se týče skupiny, kolega měl na mysli, že toto pravidlo se neuplatní, dokud skupina neexistuje. Pokud založíte skupinu "sudo" a do ní přídáte uživatele "john", bude chování stejné, jako v prvním případě. Pokud do skupiny "sudo" přidáte ještě uživatele "jack", bude totéž platit i pro Jacka.

1414

Software / Re:Nejasnosti ohledně suoders

« kdy: 19. 02. 2019, 15:22:42 »

sudo zacalo propagovat Ubuntu, osobne nechapu, proc ho vsude cpou a preferuji

Sudo byl ve své době určitý odklon od stereotypu. Stereotypem pre-Ubuntu doby bylo přihlašování jako root. Dokonce nebylo ani zvykem přihlášení na neprivilegovaného uživatele + su. Mementem doby je OpenSSH direktiva PermitRootLogin, která z Yes přešla na Without-password, a teprve po letech na No.

Sudo proti tomu zbořilo konvence a řeklo: stačí obyčejný uživatel a elevovat oprávnění budeme až podle potřeby. Bylo to v době, kdy Windows zavedly UAC. Sudo v počátku snažení bylo vyvinutějším mechanismem než UAC: UAC vycházelo z práv administrátora, ale snižovalo je směrem dolů. Sudo vycházelo z práv uživatele a povyšovalo je nahoru. Čistě teoreticky je sudo-cesta čistší. V praxi ale UAC funguje lépe. Proč? Protože sudo vyžaduje heslo u každého uprdnutí a technicky s tím nejde nic dělat. UAC, oproti tomu, může pracovat s tím, co je "téma doby".

Pokud si můžu vybrat, tak na server mi sudo nepatří, tam mi stačí su a správné metody správy. Naopak, na pracovní stanici mám raději UAC, než sudo.

1415

Software / Re:Nejasnosti ohledně suoders

« kdy: 19. 02. 2019, 15:04:13 »

Dekuji ze mas jeste silu opravovat ty nesmysly kolegy Jirsaka - prosim, ignorujte toho trotla, co to ma max vyctene z knih, ale zrejme to nikdy sam nedelal

Sice se ke vsemu ma potrebu vyjadrovat, ale to, ze je Guru fora, nic o jeho kvalitach nevypovida

Předně, díky.

Kolega Jirsák možná nevyužívá tolik historických znalostí, přesto se vyjádřil k tématu. Já jsem za jeho příspěvek rád, protože mi to nabízí vhled do myšlení "méně konzervativních" správců. Mě by nikdy nenapadlo užít ACL, abych nahradil funkci, kterou mohu zajistit daleko jednoduššími způsoby. Jsem ještě generace vychovaná otázkou: "a co se stane, když tento mechanismus selže?" a díky tomu vymýšlím možná složitější, přesto (snad?) bezpečnější řešení.

Přiznám se, že mě, v mé stařecké zaslepenosti ještě nenapadlo, že už existuje garda uživatelů, kteří považují sudo za standard a su za něco zvláštního.

1416

Server / Re:Nelze vytvořit adresář v /srv běžným uživatelem

« kdy: 19. 02. 2019, 08:39:14 »

Použít ACL a přidat uživateli postgres právo zápisu do /srv – příkaz setfacl.

To nepovažuji za dobrý nápad. Není žádný důvod, aby pg_dump volal přímo uživatel postgres. Uživatel postgres je vlastník procesu serveru a chybný krok může shodit server. Klidně práva nastavit přes ACL (i když to také nepovažuji za šťastné, protože to není univerzální postup pro různé OS a pro různé filesystémy), ale určitě užit jiného uživatele.

S tim zase nesouhlasim ja. Jakkykoli jiny uzivatel nemusi mit prava do vsech objektu v DB. Takze rozhodne at to dumpuje postgres.

Co se tyce /srv, tak doporucuji udelat tam podadresar a na nem nastavit prava pro postgres. Proc? Protoze to umoznuje mit manevrovaci prostor pro dalsi veci v /srv.

Postgres = vlastník procesu, i právo dump
Pgmaint = pouze právo dump
Obyč user = právo ostatních prací (klidně přes ACL), např. práci s dumpy.

Co mi na tom vadí je zneužívat proces serveru k pracem, to se prostě nemá dělat.

1417

Server / Re:Nelze vytvořit adresář v /srv běžným uživatelem

« kdy: 19. 02. 2019, 07:47:02 »

Použít ACL a přidat uživateli postgres právo zápisu do /srv – příkaz setfacl.

To nepovažuji za dobrý nápad. Není žádný důvod, aby pg_dump volal přímo uživatel postgres. Uživatel postgres je vlastník procesu serveru a chybný krok může shodit server. Klidně práva nastavit přes ACL (i když to také nepovažuji za šťastné, protože to není univerzální postup pro různé OS a pro různé filesystémy), ale určitě užit jiného uživatele.

1418

Server / Re:DB - ako riesia indexy?

« kdy: 18. 02. 2019, 20:56:24 »

Předpokládám, že se tady bavíme o indexech nad jednou tabulkou.

Index nad více tabulkami? Tím máte na mysli co? Napadá mě snad jedině index nad zhmotněným pohledem..?

1419

Server / Re:Nelze vytvořit adrésář, píše "permission deined" při non-root uživateli

« kdy: 18. 02. 2019, 20:43:24 »

Úplně nejbezpečněji:
1. založit nového neprivilegovaného uživatele (např. pgmaint)
2. chown pgmaint:wheel /srv (evt. pgmaint:pgmaint)
3. chmod 0750 /srv
4. su - postgres -c "createuser -s -P pgmaint"

(nebo můžete rovnou založit uživatele pgmaint s home /srv, ale pak musíte stejně pohlídat ty práva).

V tu chvíli bude mít k adresáři přístup uživatel pgmaint, a pro postgres bude superuser (takže dokáže jakoukoliv operaci s postgresem, včetně pg_dump).

Bylo by lepší, kdyby nemusel být superuserem, ale to z Vašeho dotazu není poznat.
Neumím taky posoudit, jak máte nastavený pg_hba.conf.

1420

Software / Re:Nejasnosti ohledně suoders

« kdy: 18. 02. 2019, 10:55:21 »

Su je naopak standardní, neodinstalovatelná součást systému.

Ve světe linuxu, kde si každý může sestavit distribuci jakou chce, je dost ošemetné psát o „standardní součásti systému“.

To já bych zase opatrný nebyl. Su patří do základu systému jak v Unixech (od verze 1, rok 1974), tak i podle LSB: https://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Common/LSB-Common/rcommands.html, zatímco sudo je obyčejný balík, který v systému být může, ale taky nemusí. Na některých systémech je alternativou pro sudo program doas.

Záleží na konfiguraci, obvyklá je i konfigurace, kdy vybraní uživatelé/skupiny mohou používat su bez hesla roota. root pak může mít silnější heslo.

To už není vlastnost su, ale PAM. PAM je ale také volitelný, nejde spoléhat na to, že je k dispozici.

Což stále znamená jen to, že se daný příkaz předá shellu, který su spustí.

Nehraje to moc velkou roli. Prostředí se buďto zachová původní, nebo se nastaví podle nového uživatele (parametrem). Volání přes shell je bezpečnostní pojistka, aby měl uživatel validní shell z /etc/shells. V sudo můžete stejnou kontrolu (validního shellu uživatele) nastavit konfigurací přes PAM, ale ten nemusí být všude k dispozici. Se špatně nakonfigurovaným sudo / PAM můžete kontrolu shellu obejít, což bych považoval za potenciální bezpečnostní riziko.

Primární rozdíl mezi su a sudo je v tom, že su slouží pro přepnutí na daného uživatele – používá se tehdy, když dál chci pracovat jako jiný uživatel a chová se stejně, jako kdybych se jako daný uživatel přímo přihlásil (s tou výjimkou, že můžu udělat su na uživatele, jehož heslo neznám nebo který má zakázané přihlášení).

Zde velmi nesouhlasím. Podívejte se např. do instalačních scriptů software, nebo do initscriptů. Su -c "příkaz" se volá často. Sudo se ve scriptech používá spíš zřídka, resp. nepamatuji se, kde bych to potkal.

sudoers s příkazem ALL jde proti původnímu smyslu sudo a je to taková divná a zbytečná náhrada za su.

Souhlasím bezvýhradně.

1421

Desktop / Re:Jak plnohodnotně pracovat ve VM

« kdy: 18. 02. 2019, 10:07:54 »

Já jsem na práci také provozoval virtuálku Win7 pomocí libvirtu + QXL + Spice a žádný problém jsem s plynulostí GUI neměl. Možná jsem jen ve Win7 vypnul 3D akceleraci (Aero). Virtuální grafický ovladač QXL podporuje 2D akceleraci, takže třeba surfování (scrollování) naprosto v pohodě.

VMware používá svoji vestavěnou 3D akceleraci, takže ji zkus vypnout a ponechej jen 2D + vypni Aero.

Toto je hodně subjektivní. Např. pro vzdálenou správu a sem tam něco se dá tolerovat určitá latence. Pro trvalou práci pak rozdíly lidé vnímají. Navíc je každý jiný, takže znám lidi, kteří fungují bez problémů ve stejné situaci, ve které jiní skoro nejsou schopni pracovat.

1422

Software / Re:Nejasnosti ohledně suoders

« kdy: 18. 02. 2019, 09:19:41 »

Na to rootovi stačí daleko jednodušší a s heslem neotravující: su

Které ovšem dělá něco jiného (mimo jiné přepne kontext trvale), a je to jiná aplikace z jiného balíčku než sudo, např. nemusí být nainstalovaná.

Tady jste si to asi zaměnil. Su je naopak standardní, neodinstalovatelná součást systému. Např. v debianu je to součást balíku "login" (který nejde odinstalovat). Na BSD je to součást base systemu (bez které se nedá systém instalovat).

Oproti tomu sudo je naopak balíček, který vůbec nemusí být nainstalován. Pokud nainstalujete debiana holého, nebo čisté FreeBSD, sudo v něm není.

Su nepřepíná práva trvale, běžně se volá:

Kód: [Vybrat]

su - uzivatel -c "prikaz k vykonani"

Rozdílem je, že su k elevaci práv potřebuje zadat heslo roota.
Sudo k elevaci práv potřebuje mít záznam v sudoers + (volitelně) zadat heslo volajícího uživatele.

1423

Software / Re:Nejasnosti ohledně suoders

« kdy: 18. 02. 2019, 08:00:39 »

root ALL=(ALL) ALL se přidává pro jistotu, aby mohl root změnit sám sebe na roota.

Tenhle řádek hlavně umožní rootovi spouštět pomocí sudo jakýkoli příkaz jménem jakéhokoli jiného uživatele. Třeba když chce root editovat nějaký soubor uživatele a nechce převzít jeho vlastnictví (protože pak už by se k němu ten uživatel nedostal).

Na to rootovi stačí daleko jednodušší a s heslem neotravující: su

1424

Software / Re:Nejasnosti ohledně suoders

« kdy: 18. 02. 2019, 07:52:16 »

Soubor sudoers vyjmenovává uživatele, kteří se mouhou změnit na roota.

root ALL=(ALL) ALL se přidává pro jistotu, aby mohl root změnit sám sebe na roota. To vypadá na první pohled nesmyslně, ale účel to má. Můžete mít sepsané scripty, které sudo využívají. Kdyby tento řádek chyběl, tak by scripty paradoxně fungovalo ostatním uživatelům v sudoers, ale rootovi ne . Někdy se přidává NOPASSWD, pak rootovi mohou volání sudo projít bez zdržování.

Zbytek uživatelů je na Vás, jestli je přidáte do skupiny sudo, nebo jestli je vyjmenujete ručně. Některé systémy (distribuce) ani skupinu sudo nemají, takže je nutné umět se podle situace zorientovat.

1425

Desktop / Re:Jak plnohodnotně pracovat ve VM

« kdy: 17. 02. 2019, 09:05:49 »

To se nedivte, v reálném čase to enkóduje H.264 pro 4k rozlišení.