reklama

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

Re:Nelze vytvořit adresář v /srv běžným uživatelem
« Odpověď #15 kdy: 20. 02. 2019, 07:47:50 »
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.




reklama


Re:Nelze vytvořit adresář v /srv běžným uživatelem
« Odpověď #16 kdy: 20. 02. 2019, 08:37:09 »
Na postgresu nepracujete s uživatelem postgres, ale taky jen povyšujete práva jiného uživatele.
Mícháte dohromady systémové uživatele a databázové uživatele. PostgreSQL umožňuje systémové uživatele použít pro zjednodušené přihlášení ke stejnojmennému databázovému uživateli, ale zejména pro začátečníky je potřeba v tom důsledně rozlišovat.

Zálohovat data z PostgreSQL pomocí dumpu je možné i po síti, můžete třeba databázový server běžící na Linuxu zálohovat z Windows, takže z hlediska přístupových práv k databázi je podstatné jenom to, pod jakým uživatelem se při zálohování hlásíte do databáze – lokální systémový uživatel je pro databázový server nezajímavý.

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

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. Podobné to je s různými návody na internetu. Takže pokud někdo ty účty (z hlediska bezpečnosti správně) rozdělí, musí si např. při čtení různých návodů správně převést, o kterém z účtů je v kterém případě řeč.

Re:Nelze vytvořit adresář v /srv běžným uživatelem
« Odpověď #17 kdy: 20. 02. 2019, 09:19:15 »
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:~#

Re:Nelze vytvořit adresář v /srv běžným uživatelem
« Odpověď #18 kdy: 20. 02. 2019, 09:34:02 »
Fíha, vy jste se ale rozdebatovali. nečekal sem, že se tu strhne taková debata, děkuji Vám z  toho jak mezi sebou debatujete, trochu začínám chápat další souvislosti.


Automatické zálohování mám již hotové, funguje tak, že adresář s cílem záloh je vlastníka postgres, který spouští skript pro vytváření záloh. Ten automatický skript jsem viděl, ale přijde mi moc složitý a namísto toho, abych se snažil takový skript pochopit, sem si napsal svůj.


Když bych vytvořil pgmaint, mohl bych zálohovat jen ty databáze, kterých je owner pgmaint ne? Tím pádem přístup k databázím vytvořeným jiným uživatelem by neměl přístup ne? Nebo by pgmaint převzal všechno co umí i postgres výjimkou samotného běhu postgresql procesu?

Re:Nelze vytvořit adresář v /srv běžným uživatelem
« Odpověď #19 kdy: 20. 02. 2019, 09:36:14 »
Když bych vytvořil pgmaint, mohl bych zálohovat jen ty databáze, kterých je owner pgmaint ne? Tím pádem přístup k databázím vytvořeným jiným uživatelem by neměl přístup ne? Nebo by pgmaint převzal všechno co umí i postgres výjimkou samotného běhu postgresql procesu?

Vůbec ne. Pgmaint bude superuser databáze - bude mít k databázím stejný přístup, jako uživatel postgres.
(Od toho je parametr "-s" ve volání createuser).

Rozdíl mezi uživatelem postgres a pgmaint bude "jen" v tom, že pgmaint nebude mít oprávnění upravovat konfiguraci postgresu, nebude mít možnost poškodit datové soubory posgresu, nebude moci shodit proces postgresu.

reklama


Re:Nelze vytvořit adresář v /srv běžným uživatelem
« Odpověď #20 kdy: 20. 02. 2019, 10:18:04 »
Vůbec ale neplatí, že by "role" postgres musela existovat a být superuserem.
Polemizujete s něčím, co jsem nenapsal. Psal jsem o běžných distribucích. Vy jste uváděl Debian, tam se volá

Kód: [Vybrat]
/usr/bin/pg_createcluster -u postgres $VERSION main

A server samozřejmě také běží pod uživatelem postgres. Ostatně i vy ve svém příkladu jste jako systémového uživatele – správce databáze uvedl účet postgres.

Když bych vytvořil pgmaint, mohl bych zálohovat jen ty databáze, kterých je owner pgmaint ne? Tím pádem přístup k databázím vytvořeným jiným uživatelem by neměl přístup ne? Nebo by pgmaint převzal všechno co umí i postgres výjimkou samotného běhu postgresql procesu?
Mícháte dohromady systémové uživatele (uživatele v operačním systému zapsané v /etc/passwd) a databázové uživatele (přesně to, před čím jsem varoval).

Klidně můžete pod systémovým uživatelem pg_backup spustit zálohování, které s ek serveru připojí databázovým uživatelem backup_database_1. Je to parametr -U/--username programu pg_dump.

Použít jiný systémový účet pro zálohování (jiný než účet, pod kterým běží server), je vhodné z hlediska bezpečnosti databázového serveru. Kdybyste pro zálohování použil stejný účet, jako ten, pod kterým běží databázový server, může zálohovací skript omylem např. zabít proces databázového serveru, přepsat konfiguraci nebo data, nebo třeba zaplnit disk (aniž by se mohly uplatnit kvóty, které by mohly diskový prostor pro databázi ochránit).

Něco jiného je zase databázový uživatel – ten rozhoduje o tom, k jakým databázovým objektům bude mít zálohovací skript přístup. Zde je zase z hlediska bezpečnosti nevhodný postup, pokud zálohování spouštíte pod uživatelem, který má v databázi práva superuživatele – je to jako kdybyste v systému spouštěl zálohovací skript s právy roota. Je to jednoduché – nemusíte nastavovat oprávnění, ale zároveň máte mnohem silnější oprávnění, než k zálohování potřebujete. Pro zálohování není potřeba umět žádné objekty v databázi zapisovat, mazat nebo je spouštět, ke všemu potřebujete jen práva pro čtení.

Takže pokud to chcete mít opravdu bezpečné, můžete mít v systému jiného uživatele pro běh serveru a jiného pro zálohování (můžete mít dokonce různé uživatele pro zálohování různých databází), a v databázi také speciální uživatele pro zálohování, kteří budou mít jen potřebná práva pro čtení.

Nebo můžete jít cestou nejmenšího odporu, použít systémového uživatele postgres, pod kterým běží i server, tím se přihlásit k databázi jako superuživatel, který může cokoli změnit nebo smazat. A samozřejmě je možné to různě kombinovat, např. mít dva uživatele v systému ale v databázi zálohovacího uživatele pro každou databázi zvlášť.

Z hlediska bezpečnosti je o něco důležitější ten uživatel v databázi – protože chyba ve skriptu pro zálohování by mohla odstřelit databázový server nebo smazat jeho data, ale bylo by obtížné tak nepozorovaně pozměnit data. Databázový uživatel, který má práva ke všemu, může nepozorovaně změnit data, aniž byste to zjistil. Na druhou stranu u toho databázového uživatele potřebujete spolupráci vlastníka databáze – např. když se přidá další tabulka, musí se jí nastavit oprávnění, aby ji zálohovací uživatel mohl přečíst.

Ale pokud chcete pro bezpečnost vašich dat udělat něco důležitého, začněte tím, že zálohy budete hned na místě šifrovat veřejným klíčem a privátní klíč budete mít někde off-line. To je mnohem důležitější, než jaké účty pro zálohování použijete.

Re:Nelze vytvořit adresář v /srv běžným uživatelem
« Odpověď #21 kdy: 20. 02. 2019, 10:32:45 »
Něco jiného je zase databázový uživatel – ten rozhoduje o tom, k jakým databázovým objektům bude mít zálohovací skript přístup. Zde je zase z hlediska bezpečnosti nevhodný postup, pokud zálohování spouštíte pod uživatelem, který má v databázi práva superuživatele – je to jako kdybyste v systému spouštěl zálohovací skript s právy roota. Je to jednoduché – nemusíte nastavovat oprávnění, ale zároveň máte mnohem silnější oprávnění, než k zálohování potřebujete. Pro zálohování není potřeba umět žádné objekty v databázi zapisovat, mazat nebo je spouštět, ke všemu potřebujete jen práva pro čtení.

1. Databázový uživatel = "role". Bylo by lepší držet se tohoto pojmenování.
2. Bez superusera nezazálohujete systémové databáze (globalobjects). Běžný uživatel může zálohovat pouze databáze, ke kterým má přístup. I tak to ale nebude dokonalé, protože např. zcela běžný CREATE EXTENSION bez superusera neuděláte.
3. OS je zvykem zálohovat jako root, jinak se Vám může lehce stát, že se zálohovací proces nedostane k některým souborům.

Ale pokud chcete pro bezpečnost vašich dat udělat něco důležitého, začněte tím, že zálohy budete hned na místě šifrovat veřejným klíčem a privátní klíč budete mít někde off-line. To je mnohem důležitější, než jaké účty pro zálohování použijete.

Uff, šifrování ochrání data před zneužitím, ale nezvyšují bezpečnost ve smyslu "neztratím data". Naopak šifrování (pokud uděláte chybu) riziko ztráty dat zvyšuje.

====

Kdybychom šli do důsledku, tak ideální způsob zálohy dat je kopírování souboru databáze + WAL (write ahead logs). Na to už zase je naopak potřeba mít práva číst datové soubory - a zde bych naopak ACL jako řešení doporučoval. Odpadá tím potřeba mít v databázi jakoukoliv roli (natož superusera), databázi to neblokuje v provozu. Popis je zde: https://www.postgresql.org/docs/11/continuous-archiving.html

Jako systém na zálohování a zároveň šifrování (a zároveň ne moc složitý) je podle mě Borg Backup https://borgbackup.readthedocs.io/en/stable/, plně šifrované repo se vytvoří "borg init --encryption=keyfile-blake2". Jedinou nevýhodou je, že nepodporuje pull backup, takže když zálohování selže, jediný způsob jak to zjistit je všimnout si, že nechodí logy, nebo během pravidelných údržeb. (Na pull backup existují scripty přes ssh, ale přímo podporovaná cesta to není).

Re:Nelze vytvořit adresář v /srv běžným uživatelem
« Odpověď #22 kdy: 20. 02. 2019, 11:39:17 »
2. Bez superusera nezazálohujete systémové databáze (globalobjects). Běžný uživatel může zálohovat pouze databáze, ke kterým má přístup. I tak to ale nebude dokonalé, protože např. zcela běžný CREATE EXTENSION bez superusera neuděláte.
Nemyslím si, že by se v rámci zálohování databáze měl volat příkaz CREATE EXTENSION, ani žádný jiný příkaz CREATE.

Při zálohování databáze je podle mne lepší zálohovat jenom data, struktura by měla být zálohována zvlášť. Struktura bývá stejná na více prostředích nebo třeba na replikačním serveru. Pokud mám zazálohovaná jenom data, mohu je snadno obnovit i na jiném prostředí a nepřekáží mi tam DDL příkazy.

3. OS je zvykem zálohovat jako root, jinak se Vám může lehce stát, že se zálohovací proces nedostane k některým souborům.
Ano, to je to jednoduché řešení. Akorát mi připadá zvláštní oddělovat uživatele pro zálohování, aby omylem neodstřelil databázový proces nebo nepřepsal konfiguraci, a zároveň při zálohování používat oprávnění superuživatele.

Uff, šifrování ochrání data před zneužitím, ale nezvyšují bezpečnost ve smyslu "neztratím data". Naopak šifrování (pokud uděláte chybu) riziko ztráty dat zvyšuje.
Já jsem ale nepsal, že by to zvyšovalo bezpečnost ve smyslu „neztratím data“. Jenom uvádím, že riziko úniku dat ze záloh je mnohem závažnější, než riziko, že mi zálohovací skript omylem smaže databázové soubory. I kdyby se ten zálohovací skript zbláznil a začal mazat soubory, pořád přijdu maximálně o data od poslední zálohy. Pokud by to byl problém, je stejně zálohování „jednou za čas“ nedostatečné a musím řešit průběžnou replikaci dat. Replikace ale nenahrazuje zálohování,  protože když smažete/přepíšete data v primárním zdroji, jsou velice rychle smazaná/přepsaná i v replice.

Re:Nelze vytvořit adresář v /srv běžným uživatelem
« Odpověď #23 kdy: 20. 02. 2019, 11:51:52 »
Ano, to je to jednoduché řešení. Akorát mi připadá zvláštní oddělovat uživatele pro zálohování, aby omylem neodstřelil databázový proces nebo nepřepsal konfiguraci, a zároveň při zálohování používat oprávnění superuživatele.

Na to není nic zas tak zvláštního. Cokoliv, co jde provozovat s oprávněními < root, je vhodné tak činit.

Na druhou stranu, samotný zálohovací proces už nemá na výběr, ten musí být co nejrobustnější. Nechcete riskovat, že se Vám nezazálohuje část dat nebo část nastavení jen kvůli tomu, že Vám nedošlo (nezkontroloval jste, rozpadlo se po updatu), kde je potřeba oprávnění nastavit. Tam už zkrátka není vyhnutí. (Fungují tak všechny zálohovací systémy, ať už pasivní, nebo s agentem, ať už na Linuxu, Unixech či Windows).

Ze stejného důvodu se vždy zálohování dělá systémem "Zálohovat VŠE" mínus "vyjmenované exclusions", protože opačný postup (zálohovat jen vybraná umístění) vede dřív či později k neštěstí.

Omezit zálohovací proces lze např. pomocí SElinux.


Re:Nelze vytvořit adresář v /srv běžným uživatelem
« Odpověď #24 kdy: 20. 02. 2019, 18:41:59 »
Šifrování záloh v momentu, kdy je vytvářím není potřeba, na tom mám zakoupenou službu enterprise zálohovací řešení, které to zálohuje (tedy nejspíš i šifruje). Já dělám jen to, že uživatelem postgres dělám dump všech databází do /srv/bla/bla/zalohy/ odkud si to ten zálohovací systém už zálohuje do nějaké storage nebo tak něco. Funguje mi to zatím dobře, s tím, že používám něco jako: su - postgres -c /path/to/pgbackup.sh, který udělá dumpy do /srv/bla/bla/zalohy/ kde vlastník je uživatel postgres a skupina root.

Každopádně Vám oběma děkuji. Zvažujete různé možnosti. Ale já z toho o čem se bavíte furt nechápu jestli se mám tedy pokoušet vytvářet pgmaint odděleného uživatele pro tvoření pgdumpů, či to stačí tak jednoduše, jak jsem udělal. Nemyslím si, že by se tím mohla databáze nějak "odstřelit", používám vzhledem k databázi jen dvě věci:
  • Vypsání si pomocí uživatele postgres jaké databáze existují.
  • Na základě toho výpisu z jednotlivých databází udělat dumpy a uložit je do /srv/bla/bla/zalohovani/.

Re:Nelze vytvořit adresář v /srv běžným uživatelem
« Odpověď #25 kdy: 20. 02. 2019, 19:10:06 »
Můžete to klidně dál dělat pod uživatelem postgres. :)

Moje poznámka byla spíš ke "zdravým návykům", prostě jsem zvyklý to oddělovat a není to žádná práce navíc a střípek bezpečnosti navíc to je.

Re:Nelze vytvořit adresář v /srv běžným uživatelem
« Odpověď #26 kdy: 20. 02. 2019, 19:27:53 »
tedy nejspíš i šifruje
V tom případě je důležité jenom to, jestli na to od nich máte papír. :-) Aby kdyby ta data ze záloh unikla, nebylo to na vás…

Ale já z toho o čem se bavíte furt nechápu jestli se mám tedy pokoušet vytvářet pgmaint odděleného uživatele pro tvoření pgdumpů, či to stačí tak jednoduše, jak jsem udělal.
Já bych začal tímhle jednoduchým řešením. Podle toho, co píšete, ten skript ani nic nemaže, jenom spouští psql a pg_dump. Oprávnění nastavená tak, aby vám ten skript nemohl jen tak někdo přepsat, předpokládám máte. Takže pravděpodobnost, že ten skript napáchá nějaké škody, je velmi nízká. Vylepšovat to, aby ten skript běžel pod jiným uživatelem, můžete později, až vám ten současný systém bude bezpečně fungovat a budete vědět, že poznáte, když se záloha nevytvořila nebo není kompletní nebo když se tím enterprise řešením neodzálohovala pryč. To jsou mnohem větší rizika.

Re:Nelze vytvořit adresář v /srv běžným uživatelem
« Odpověď #27 kdy: 20. 02. 2019, 20:26:19 »
Já bych začal tímhle jednoduchým řešením. Podle toho, co píšete, ten skript ani nic nemaže, jenom spouští psql a pg_dump. Oprávnění nastavená tak, aby vám ten skript nemohl jen tak někdo přepsat, předpokládám máte. Takže pravděpodobnost, že ten skript napáchá nějaké škody, je velmi nízká. Vylepšovat to, aby ten skript běžel pod jiným uživatelem, můžete později, až vám ten současný systém bude bezpečně fungovat a budete vědět, že poznáte, když se záloha nevytvořila nebo není kompletní nebo když se tím enterprise řešením neodzálohovala pryč. To jsou mnohem větší rizika.

Já bych možná jen doporučil ten script volat přímo z crontabu uživatele postgres, nikoliv přes su. Tj. crontab -u postgres -e.

Vilith

  • *****
  • 521
    • Zobrazit profil
Re:Nelze vytvořit adresář v /srv běžným uživatelem
« Odpověď #28 kdy: 20. 02. 2019, 21:00:40 »
Já bych začal tímhle jednoduchým řešením. Podle toho, co píšete, ten skript ani nic nemaže, jenom spouští psql a pg_dump. Oprávnění nastavená tak, aby vám ten skript nemohl jen tak někdo přepsat, předpokládám máte. Takže pravděpodobnost, že ten skript napáchá nějaké škody, je velmi nízká. Vylepšovat to, aby ten skript běžel pod jiným uživatelem, můžete později, až vám ten současný systém bude bezpečně fungovat a budete vědět, že poznáte, když se záloha nevytvořila nebo není kompletní nebo když se tím enterprise řešením neodzálohovala pryč. To jsou mnohem větší rizika.

Já bych možná jen doporučil ten script volat přímo z crontabu uživatele postgres, nikoliv přes su. Tj. crontab -u postgres -e.

Kód: [Vybrat]
0 22 * * * /var/lib/postgresql/pg_backup_rotated.sh
a pouzivam ten script z wiki

 

reklama