reklama

Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Miroslav Šilhavý

Stran: 1 [2] 3 4 ... 113
16
Vy se na to ovšem díváte z opačné strany. Systémový uživatel postgres je jediný způsob, jak se (na Linuxu) do čerstvě nainstalované databáze můžete přihlásit. Nebo-li systémový účet postgres je ten účet, který je určený pro administraci databáze. Můžete použít mapování systémových uživatelů na databázové uživatele, ale opět je to nestandardní konfigurace. Běžné distribuce ale tenhle účet postgres „zneužívají“ i k tomu, že pod ním spouští databázový server.

Ono je to ale přesně naopak. Základem bezpečnosti je, že musíte mít dedikovaný účet pro běh serveru. Tím bývá uživatel posgres, někdy třeba psql. Vůbec ale neplatí, že by "role" postgres musela existovat a být superuserem.

https://www.postgresql.org/docs/11/app-initdb.html - viz parametr --username=:

Citace
Kód: [Vybrat]
-U username
--username=username
Selects the user name of the database superuser. This defaults to the name of the effective user running initdb. It is really not important what the superuser's name is, but one might choose to keep the customary name postgres, even if the operating system user's name is different.

Poté je běžné provést su - postgres -c "createuser -s -P jmeno_spravce"

Podle situace se pak v pg_hba.conf (https://www.postgresql.org/docs/11/auth-pg-hba-conf.html) nastaví mechanismus autentikace. Je možné zvolit peer, kdy lokální uživatel téhož usernamu nebude tázán na heslo. Já raději (právě i kvůli tomu, že často se využívá externí připojení) doporučuji i na lokální připojení využívat scram-sha-256 (případně md5 kvůli kompatibilitě se staršími klienty) a heslo ukládat v .pgpass. Je to lepší návyk, předejde se tím možnostem oponinutí bezpečnosti.

Já s vámi souhlasím, že principiálně správně je mít dva účty – jeden pro správu databáze a druhý, pod kterým poběží databázový server. A ideálně ještě další, třeba samostatný účet pro zálohování. Běžné linuxové distribuce to ale pokud vím nerozlišují a pro vše používají účet postgres.

Dívám se na Debian, dívám se na FreeBSD, ale nevidím tam, že by distribuce dělala cokoliv. V minulosti (v době dřevěné, pre-autovacuum) se volala údržba databáze (a debian měl heslo uložené v souboru). Dnes už tam není žádný task:

Kód: [Vybrat]
root:~# crontab -u postgres -l
no crontab for postgres

Kód: [Vybrat]
root:~# find /etc/cron* -type f -exec grep "postgres" {} \;
root:~#

17
Jenom jsem upozorňoval na to, že to použití jiného uživatele jde nad rámec toho, s čím počítá např. oficiální dokumentace PostgreSQL, protože tam se počítá s jedním uživatelem postgres, který slouží jak k běhu serveru, tak pro jeho správu. Takže pokud použijete uživatele dva (nebo více), musíte na to myslet i v budoucnosti a používat toho správného uživatele pro konkrétní činnosti.

Toto bych ale považoval za samozřejmost správy. Na systému nepracujete stále s uživatelem root, ale povyšujete práva podle potřeby. Na postgresu nepracujete s uživatelem postgres, ale taky jen povyšujete práva jiného uživatele. To je základní koncept bezpečnosti, o kterém se nemusí psát. (Podobně není v dokumentaci napsáno, že nemáte zakládat uživatele s právy superusera zbytečně, nebo že si nemáte psát hesla na papírek na monitoru.)

Před užíváním uživatele posgtgres na binárky (tj. rozšířeně i na scripty) se v dokumentaci varuje - právě kvůli přepisu jich samých (a potažmo i dat, samozřejmě): https://www.postgresql.org/docs/11/postgres-user.html.

Zde https://www.postgresql.org/docs/11/backup-dump.html se popisuje zálohování, s tím, že jsou potřeba práva superusera. O tom, že by se tato operace měla dělat uživatelem postgres (vlastníkem procesu), zde není ani zmínka, byť by to bylo to nejjednodušší, co by mohli doporučit.




18
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.

19
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.

20
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.

21
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.

22
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.

23
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.

24
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.

25
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..?

26
Ú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.

27
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ě.

28
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.

29
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.

30
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

Stran: 1 [2] 3 4 ... 113

reklama