Příspěvky

2701

Sítě / Re:Routování klientů připojených přes Wi-Fi na konkrétní IP

« kdy: 20. 02. 2019, 16:37:07 »

moj ciel je aby z pre klientov pripojenych na AP bola dostupna len jedina jedna stranka beziaca na mojom servery aj ked si do browsra zadaju cokolvek ine.

Toho se obecně nedá docílit, protože zadanou adresu může už prohlížeč vyhodnotit jako chybnou a ani se na ní nikam ptát nebude. Pokud byste chtěl docílit alespoň únosu adres v platném formátu, musel byste provozovat vlastní DNS server, který by na jakýkoli dotaz odpověděl odkazem na váš server. Čímž samozřejmě způsobíte to, že se na ten server přesměrují i všechny ostatní požadavky uživatelova zařízení – na aktualizace, na stažení e-mailů, na chat přes WhatsApp, Messenger a další… A záleží na tom, jak dlouhé timeouty vašim odpovědím nastavíte, uživateli pak ty aplikace nemusí fungovat ještě dlouho po té, co vaši síť opustí. Navíc vám to nebude fungovat, když uživatel použije HTTPS, protože nebudete mít důvěryhodný certifikát pro příslušnou doménu. A dnes už většina toho, co uživatelé používají, běží na HTTPS.

Shrnuto a podtrženo, na vašem místě bych se do něčeho takového nepouštěl, zejména když nevíte, co děláte. Většinou to nebude fungovat a navíc uživateli můžete rozbít přístup k internetu. Pravděpodobně existuje lepší způsob, jak docílit toho, čeho se snažíte docílit – pokud byste nám to prozradil.

2702

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

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

2703

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

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

2704

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

« 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č.

2705

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

« kdy: 20. 02. 2019, 07:31:30 »

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.

Pokud se bavíme o Linuxu, tam, už je ACL standardem hezkých pár let. A v tomto případě se ACL nastavuje na jeden jediný adresář /srv, takže nějaké kopírování nebo přesouvání tohoto adresáře bude mít stejný problém i s řešením přes skupinu – pokud ten adresář vytvoříte znova, budete muset znova ta práva nastavit.

Mimochodem ta ACL se do Linuxu zavedla právě proto, aby se obešlo omezení na jednoho vlastníka a jednu skupinu. Pokud potřebujete přidat oprávnění jednomu dalšímu uživateli, dá se to přes skupinu obejít. Pokud by těch uživatelů bylo víc a některým potřebujete povolit zápis a jiným jenom čtení, s klasickými oprávněními pro uživatele, skupinu a ostatní jste v koncích.

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.

Nikoli, ACL přidávají oprávnění dalším uživatelům na úrovni jádra operačního systému. Pokud byste ten disk vyndal a přimontoval do 15 let starého systému, kde nebude podpora ACL, neznamená to, že by k datům dostal přístup někdo další – ACL tam nebudou, tím pádem nebudou mít k datům přístup ti uživatelé, kteří jej měli pomocí ACL a přístup zůstane omezeným pouze na ty uživatele, kteří jsou přímo vlastníky nebo ve skupině. Okruh uživatelů by se tedy zúžil.

2706

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

« kdy: 20. 02. 2019, 07:31:03 »

To bezpečné/standardní se vztahuje k tomu, jestli použít uživatele postgres nebo jiného uživatele. To, zda použijete řešení přes skupinu nebo ACL s tím nesouvisí – obojí můžete udělat jak s uživatelem postgres tak s jiným uživatelem.

Ještě jsem chtěl doplnit, že to řešení Miroslava Šilhavého bych nenazýval přehnaně dokonalým – používat dedikované uživatele pro jednu konkrétní činnost je dobré řešení a často je to relativně snadné, jako v tomto případě. Abych to nazýval „přehnané“, musela by tam být ještě spousta dalších opatření. 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.

2707

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

« kdy: 20. 02. 2019, 07:11:52 »

Ano, chci vytvářet dumpy. /srv/path/to/zalohovani/ je nezbytné.
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é. A klidně můžu zálohovací skript spouštět uživatelem postgres a mohu ho nastavit vlastníkem /srv/path/to/zalohovani/ .

Chápu vás správně?

To bezpečné/standardní se vztahuje k tomu, jestli použít uživatele postgres nebo jiného uživatele. To, zda použijete řešení přes skupinu nebo ACL s tím nesouvisí – obojí můžete udělat jak s uživatelem postgres tak s jiným uživatelem.

2708

Software / Re:Nejasnosti ohledně suoders

« kdy: 19. 02. 2019, 21:57:22 »

Tady jsem jeste zapomnel dodat, ze prave a jedine root ma pravo se prepnout na jineho uzivatele.

Ve skutečnosti to může udělat proces, který má capability CAP_SETUID (resp. CAP_SETGID pro změnu skupiny). Ale to už jsme opravdu světelné roky za původním dotazem.

A pak se ještě hodí dodat, že binárky su i sudo mají nastavený setuid bit, který znamená „spusť pod uživatelem, který je vlastníkem souboru“. Tím je zařízené, že su i sudo se vždy spustí pod rootem, ať je spustí kdokoli, a proto pak mohou provádět ty „kejkle“ a přepínat kontext uživatele. Není to tedy žádná speciální vlastnost těchto programů, že by měly nějaké speciální výsady vůči linuxovému jádru. Jenom využívají setuid bit a toho, že jsou díky němu vždy spuštěny pod rootem. Programy jako su nebo sudo si může napsat každý – ale setuid (a setgid) bit jsou velmi nebezpečná hračka, zejména pokud tu binárku vlastní root.

2709

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

« kdy: 19. 02. 2019, 21:47:44 »

Pgmaint = pouze právo dump

Jenže scientific tam nechce ty databáze dumpovat (což by ostatně bylo rozumné dělat do jiného adresáře než /srv), ale chce je naopak obnovovat.

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

Jenže to, že postgres je uživatel pouze pro proces serveru, jste si vymyslel vy – samotnými autory PostgreSQL tak chápán není. Já s vámi souhlasím, že principiálně čisté řešení je takové, kdy server běží pod uživatelským účtem, který se k ničemu jinému nepoužívá. Ovšem neradil bych to, že má prokopávat tuto perfektně čistou cestu, někomu, kdo se potřebuje na takovéhle věci ptát na diskusním fóru. V tomto případě bych upřednostnil řešení, které sice není principiálně úplně čisté, ale je standardní.

2710

O serveru Root.cz / Re:Přihlašování do diskusního fóra

« kdy: 19. 02. 2019, 21:21:49 »

Možná je důležité, že se přihlašuju přes OpenID, konkrétně přes MojeID. Dříve jsem se tu určitě nemusel přihlašovat znova každý den. A tu druhou chybu (přesměrování na jinou diskusi po přihlášení) jsem tu nezaznamenal nikdy, přitom jsem si vždy otevřel více témat v záložkách a pokud jsem byl náhodou odhlášen, přihlásil jsem se v první záložce, kde jsem chtěl odpovědět, a vrátil jsem se na správné místo.

2711

O serveru Root.cz / Přihlašování do diskusního fóra

« kdy: 19. 02. 2019, 08:52:37 »

V poslední době (myslím, že od změn 28. 1.) se chová divně přihlašování do diskusního fóra. Za prvé není možné být přihlášený na více počítačích – když se přihlásím na jednom a pak na druhém, na prvním příště nejsem přihlášen.

Co je ale horší, po přihlášení se dostanu do posledního otevřeného fóra, ne do fóra, ze kterého jsem se začal přihlašovat. Tj. když otevřu několik diskusních fór v záložkách a v jedné ze záložek se přihlásím, po přihlášení se dostanu do fóra z poslední otevřené záložky. Myslím, že z toho pak vznikají příspěvky zařazené úplně chybně jako např. tento: https://forum.root.cz/index.php?topic=20772.msg307142#msg307142

2712

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

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

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

2713

Software / Re:Nejasnosti ohledně suoders

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

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

Rozdílem je, že su k elevaci práv potřebuje zadat heslo roota.

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.

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

Kód: [Vybrat]

su - uzivatel -c "prikaz k vykonani"

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

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

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

sudo lze nakonfigurovat i tak, že vyžaduje zadání hesla roota nebo hesla cílového uživatele.

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í). sudo bylo původně zamýšleno pro spouštění konkrétních příkazů s oprávněními jiného uživatele – takový suid bit na steroidech. Např. aby správce webového serveru mohl bez oprávnění roota restartovat webový server, který při startu oprávnění roota potřeboval. sudoers s příkazem ALL jde proti původnímu smyslu sudo a je to taková divná a zbytečná náhrada za su.

2714

Software / Re:Nejasnosti ohledně suoders

« kdy: 18. 02. 2019, 08:38:28 »

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

2715

Software / Re:Nejasnosti ohledně suoders

« kdy: 18. 02. 2019, 07:58:06 »

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

Nikoli, je to oprávnění spouštět programy jménem jiného uživatele – nemusí to být jenom root.

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