Portál AbcLinuxu, 26. dubna 2024 12:42
Za normálních okolností platí, že má každý uživatel přístup do své e-mailové schránky, a nikam jinam. Jenže někdy může být výhodné, aby mohl přistupovat i jinam. Přinejmenším se tak omezí zbytečné přeposílání zpráv a lépe se udržuje pořádek v poště u pracovních týmů.
Pokud se pro komunikaci s členy týmu (a uvnitř tohoto týmu) používá e-mail, typicky to vypadá tak, že někdo dostane zprávu a tu hned přepošle jednomu nebo všem členům. Případně se založí speciální schránka pro celý tým. Obě řešení jsou jednoduchá, ale mají dost nepříjemné vlastnosti.
Přeposílání zpráv vede k tomu, že se jednotlivým lidem zapleveluje schránka – buď jim zprávy padají mezi všechny ostatní, anebo si tito lidé vytvoří nějaká třídicí pravidla. Odpovědi směřující mimo tým se pak musejí posílat opět všem členům (nebo přinejmenším některým), aby byli v obraze. Výsledkem je mnoho zbytečně generovaných a posílaných zpráv. Navíc pokud člen týmu, který obdržel zprávu zvenčí jako první, tuto nepřepošle, nemá ji nikdo k dispozici.
Druhá možnost, tedy vytvoření samostatné schránky, je opět problematická. Sice umožňuje udržovat veškerou korespondenci pohromadě, ale pokud je někdo členem více týmů, musí mít ve svém klientském programu pro každý tým samostatný účet a opět to vede k nepořádku a k obtížné práci. Navíc nelze definovat přístupová práva a zabránit například zbytečnému smazání zpráv nebo úpravám zpráv již odeslaných.
Uvedené neduhy lze odstranit používáním sdílených složek a definicí přístupových práv ke každé z nich. Každý uživatel pošty pak může nasdílet některé své složky a přesně určit, kdo bude mít ke které jaká práva. Lze to samozřejmě udělat i u speciálních poštovních účtů založených pro účely fungování týmu nebo projektu.
Drobná terminologická poznámka: Když je v souvislosti s protokolem IMAP řeč o schránkách, může se jednat jak o schránky jako takové, tak i o poštovní složky. Pojmy „schránka“ a „složka“ tak trochu splývají. Někde lze říkat „schránka“ všem složkám určitého uživatele dohromady, někde ale (například u veřejných složek) tuto definici použít nejde. Následující odstavce budou obsahovat oba pojmy v takových kontextech, aby bylo pokud možno dostatečně jasné, o co se jedná.
Program Dovecot (verze 1.2) podporuje v zásadě tři způsoby sdílení poštovních složek. Jednak to jsou veřejné schránky (ve veřejném jmenném prostoru; vytváří je správce), sdílené složky uživatelů (každý uživatel rozhoduje o tom, co bude jak sdílet) a sdílení přes symbolické odkazy v souborovém systému (primitivní metoda – správce vytvoří poštovní složku jako symbolický odkaz na jinou poštovní složku).
Postupně se podíváme na první dvě metody, protože každá je vhodná pro trochu jiné situace (sdílení přes symbolické odkazy je již překonáno a není žádný závažný důvod ho používat). Každá z obou metod umožňuje využívat přístupové seznamy (ACL) a ovlivňovat tak, kdo bude mít ke zprávám jaký přístup.
Plnohodnotné nastavování přístupových práv přes rozšíření IMAP ACL (podle RFC 4314) je k dispozici až od verze 1.2, verze 1.1 podporuje sice přístupové seznamy, ale nelze je nastavovat z klientských programů (musí je nastavovat ručně správce). Pro řádné využívání ACL je tedy potřeba použít Dovecot 1.2.
Sdílené složky se cílovému uživateli (tomu, kdo k nim získal práva) objeví v celkové hierarchii složek. Klientské programy mají možnost rozlišovat složky podle jmenných prostorů, kde se nacházejí. Konkrétní činnosti, které uživatel ve složkách může provádět, závisí na tom, jaká práva mu sdílející uživatel přidělil.
Když potom například přijde zpráva do sdílené složky (buď ji tam zařadí server, typicky podle pravidel Sieve, anebo ji tam přesune nějaký uživatel ručně), objeví se všem uživatelům, kteří mají právo danou složku číst. Na vložení zprávy do složky nebo k další manipulaci se zprávou je samozřejmě potřeba mít příslušná práva – o jejich přidělení rozhoduje buď vlastník účtu, případně některý z uživatelů, kterým vlastník poskytl právo administrace.
Konfigurace programu Dovecot pro podporu sdílení složek a nastavování ACL spočívá ve třech krocích:
Nastavení je třeba věnovat náležitou pozornost, protože i drobná chyba může dost zásadně změnit chování serveru nebo ho zcela znefunkčnit.
Základním a současně nejjednodušším krokem je zapnutí pluginů, které budou poskytovat potřebnou funkcionalitu. Jedná se celkem o tři pluginy – dva pro protokol IMAP (pro vlastní funkci a pro nastavování) a jeden pro LDA, tedy doručovacího agenta. Následující výňatky z konfiguračního souboru /etc/dovecot/dovecot.conf ukazují, jak takové nastavení vypadá:
protocol imap {
mail_plugins = quota imap_quota acl imap_acl
}
protocol lda {
mail_plugins = sieve quota acl
}
Ukázka obsahuje jen řádky, které se změnily oproti konfiguraci v minulém dílu. Zůstaly pluginy pro kvóty a pro Sieve, nově přibyly pluginy pro ACL a pro nastavování ACL prostřednictvím rozšíření protokolu IMAP. Toto nebylo nic těžkého – možná jde jen o to si uvědomit, že se nesmí vynechat nastavení pro komponentu LDA, protože jinak by sdílené složky nešly využívat pro doručování (v pravidlech Sieve).
Před vlastní prací na konfiguraci neuškodí podívat se na to, co to vlastně jsou (v pojetí poštovního serveru) jmenné prostory, k čemu slouží a jak se s nimi pracuje. Jmenné prostory protokolu IMAP jsou definovány RFC 2342 a program Dovecot tuto specifikaci plně podporuje.
Zjednodušeně řečeno, existují v zásadě tři typy jmenných prostorů, v nichž se lze pohybovat: jmenné prostory uživatele, jmenné prostory ostatních uživatelů a veřejné jmenné prostory. První přísluší aktuálnímu uživateli, druhé všem ostatním uživatelům, třetí jsou pro všechny společné. U poštovních serverů umožnujících anonymní přístup bude první typ vždy prázdná množina (druhý obvykle také), naopak ve veřejném mohou být nějaké prostory (a v nich obsažené složky) k dispozici.
Jmenných prostorů v každé skupině může být více. Nejčastějším případem je existence více veřejných prostorů, které mohou být využívány pro nejrůznější účely, například jako adresáře uživatelů uložené na IMAP serveru. Každý jmenný prostor pak může mít samostatné úložiště.
Server plně podporující jmenné prostory poskytuje klientům možnost zjistit, jaké jmenné prostory jsou k dispozici, pomocí jakého prefixu je identifikovat a jaký separátor hierarchie použít. Prefix je řetězec používaný na začátku cesty ke schránce/složce, separátor hierarchie pak odděluje jednotlivé úrovně cesty (prefix a pak jednotlivé složky). Je dobré používat stejný separátor pro všechny jmenné prostory, předejde se tím případným problémům s výpisem složek.
Prefix pro osobní jmenný prostor uživatele bývá standardně prázdný, prefixy pro ostatní jmenné prostory mohou být tvořeny prakticky libovolně – ovšem s ohledem na to, aby nekolidovaly jak vzájemně, tak s názvy složek. Jako separátor se nejčastěji používá lomítko („/“), případně tečka („.“) – opět jde o to, aby to byl znak, který se nevyskytuje v názvech jmenných prostorů a složek.
Potřebné informace, tedy prefixy a separátory (případně ještě s dalšími informacemi), poskytuje server na vyžádání příkazem NAMESPACE. Podle takto získaných informací se klient musí zařídit, čili používat pro práci s příslušnými jmennými prostory odpovídající prefixy a separátory.
Při veškeré dosavadní práci s programem Dovecot se využíval jen jediný jmenný prostor – a to ten, který přísluší uživateli (soukromý jmenný prostor). Pro sdílení složek bude potřeba nastavit také jmenný prostor ostatních uživatelů. V okamžiku, kdy se definuje více jmenných prostorů, musí se i výchozí jmenný prostor (pro uživatele) definovat explicitně.
namespace private {
prefix =
separator = /
inbox = yes
}
Takto se nadefinuje soukromý jmenný prostor uživatele. Má prázdný prefix, jako separátor je nastaveno lomítko a parametr inbox říká, že složka pro doručenou poštu (INBOX, může být pouze v jednom jmenném prostoru) bude definována právě zde.
Dále je potřeba přidat jmenný prostor pro přístup do složek ostatních uživatelů (typu shared). Bude to podobné, jen o něco složitější:
namespace shared {
prefix = shared/%%d/%%n/
separator = /
location = maildir:/var/mail/virtual/%%d/%%n/Maildir:INDEX=/var/mail/virtual/%d/%n/shared/%%d/%%n
subscriptions = no
list = children
inbox = no
}
Prefix je v tomto případě složen z označení shared (společné pro všechny sdílené složky) a dále z domény a uživatelského jména uživatele, jemuž patří příslušné sdílené složky. Separátorem je opět lomítko. Zajímavější to je ale u parametru location (umístění úložiště), protože tam je jednak cesta k příslušnému podstromu pošty sdílejícího uživatele, ale také cesta k indexovým souborům (nastavená pomocí INDEX) – ta je tvořena podadresářem shared v adresáři uživatele a pod ním je další hierarchie podle sdílejících uživatelů. Může to vyhlížet hrůzostrašně, ale je pouze potřeba se zorientovat v tom, co je který uživatel, pak už je to jednoduché.
Jak si můžete všimnout, znak procent je tu v některých případech zdvojený. To je právě za účelem rozlišení jednotlivých uživatelů. Platí zde pravidlo, že zdvojený znak označuje sdílejícího uživatele, kdežto znak jednoduchý toho uživatele, který ke sdíleným složkám přistupuje.
Zbývají ještě tři parametry. První je subscription – ten říká, zda se mají pro tento jmenný prostor vytvořit data pro správu „odběru“ (čili zda klient složky sleduje). Protože si každý uživatel spravuje odběr sám, bude tato volba vypnutá (no), což v důsledku znamená, že se správa přenáší na nadřazený jmenný prostor, kterým je v tomto případě soukromý prostor uživatele (to je dáno tím, že má prázdný prefix).
Parametr list slouží k určení, jak se bude obsah jmenného prostoru klientům vypisovat. Pokud je zde children, pak se vypíše jen tehdy, pokud v něm něco je. Další možnosti jsou yes (vypíše se vždy), nebo no (nevypíše se nikdy). Poslední parametr zakazuje složku INBOX – v tomto jmenném prostoru se složka INBOX nepoužívá.
Poslední ze tří kroků konfigurace je nastavení správy ACL. Informace o tom, jaká přístupová práva má kdo nastavena, je totiž potřeba někde ukládat – a to „někde“ se musí nastavit. Možností je více. V níže uvedeném řešení se ACL ukládají přímo v jednotlivých schránkách (jejichž uživatelé zapnuli sdílení), konkrétně v souborech nazvaných dovecot-acl. Je tu ale ještě jeden problém – sdílené složky se nezobrazují uživatelům, jimž byly nasdíleny (uživatelé musí přímo zadat jejich cestu, na výpisu složek je nemají).
Tento problém lze vyřešit globálním úložištěm ACL, kde budou uloženy informace, kdo komu sdílí přístup (samotné ACL informace ovšem zůstávají uloženy u jednotlivých schránek). V jednoduchých případech (tj. když se sdílí jen málo složek a jen malému počtu uživatelů) si lze vystačit s obyčejným souborem:
plugin {
acl = vfile
acl_shared_dict = file:/var/mail/shared/shared-mailboxes.db
}
První parametr říká, jak budou uloženy informace o ACL. V tomto případě se bude jednat o soubory pro jednotlivé složky; nevyužívají se globální přístupové seznamy, které by definoval administrátor a měly by přednost před tím, co si nastaví jednotliví uživatelé. Druhý uvedený parametr je cesta k souboru se seznamem nasdílených složek.
Při rozsáhlejším využití takové řešení brzy narazí na problémy s výkonem. Pak je vhodnější, aby byly informace uložené v databázi. Lze použít různé databáze (samozřejmě podle toho, jak byl Dovecot zkompilován – viz starší díly seriálu). Jedna z možností je například použít SQLite, což je výhodné proto, že není třeba řešit žádný samostatný databázový server, přístup do databáze je přes knihovní funkce.
plugin {
acl = vfile
acl_shared_dict = sqlite:/etc/dovecot/sqlite-acl.conf
}
Tím je vyřešena konfigurace na globální úrovni, teď je potřeba nakonfigurovat přístup k databázi. Uvedený soubor /etc/dovecot/sqlite-acl.conf musí obsahovat údaje potřebné pro správnou práci s databází SQLite:
connect = /var/mail/shared/acl.sqlite
map {
table = acls
pattern = shared/shared-boxes/user/$to/$from
value_field = valid
fields {
mbfrom = $from
mbto = $to
}
}
Tento soubor definuje jednak cestu k databázovému souboru (parametr connect) a dále pak mapování databáze na rozhraní programu Dovecot. Tabulka se bude jmenovat acls, vzorek pro dotazovací klíč odpovídá formátu používanému i při ukládání do souboru. Podle dotazovacího klíče se vrací hodnota, ta je u ACL dotazů vždy rovna 1 – v tomto případě to bude atribut valid. Atributy mbfrom a mbto jsou mapovány na proměnné from a to. Při použití této konfigurace bude SQL definice tabulky vypadat takto:
CREATE TABLE acls ( mbfrom VARCHAR(100) NOT NULL, mbto VARCHAR(100) NOT NULL, valid CHAR(1) NOT NULL DEFAULT '1', PRIMARY KEY (mbfrom, mbto) );
Do této tabulky si bude Dovecot ukládat stejné údaje (tedy existující sdílení) jako v případě souboru. Databázi je samozřejmě potřeba vytvořit předem a nastavit jí přístupová práva pro čtení i zápis uživateli, pod kterým běží procesy pracující nad schránkami (tj. vmail).
Při vytváření složek prostřednictvím protokolu IMAP se práva dědí v tom smyslu, že pro nově vytvořenou složku se zkopíruje kompletní ACL ze složky nadřazené. Při změně ACL u nadřazené složky se však už ACL u potomků nemění.
Nepříjemnou vlastností využívání ACL (resp. nastavování ACL přes protokol IMAP) je špatná podpora u klientského softwaru. Například Mozilla Thunderbird (a to i ve verzi 3.0) podporuje ACL jen ve smyslu zobrazení – nastavovat nic nejde. KMail ve verzi 1.13 podporuje do určité míry i nastavování ACL (ve smyslu nastavování některých druhů práv), nicméně občas uživatele „odmění“ zhroucením celého programu. Lze však očekávat, že se podpora v blízké budoucnosti zásadním způsobem zlepší.
Možnosti ohledně správy ACL jsou nesrovnatelně větší. Existuje možnost (pro správce) vytvářet skupiny, nastavovat jim práva a vkládat do nich uživatele. Další možností je přístup ověřeným uživatelům, případně všem uživatelům – to je však standardně z bezpečnostních důvodů zakázáno a pokud by ho někdo chtěl umožnit, je třeba v konfiguraci v sekci plugin nastavit acl_anyone = allow.
V některých případech je výhodné mít na serveru i složky, které jsou veřejné a nejsou spjaty s žádným konkrétním uživatelem. Příkladem jsou složky se zprávami, které se týkají celé firmy. Jinou situací je využití IMAP složek k jiným účelům, tedy například pro uložení adresáře nebo kalendáře (toto využívají některá groupwarová řešení).
Pro veřejné složky jsou určeny samostatné jmenné prostory (jeden či více, podle potřeby), přes které se tyto složky zpřístupní. Že jsou složky veřejné, vůbec neznamená, že by nešla nastavovat práva nebo že by měl automaticky každý oprávnění dělat tam cokoliv. Tak to samozřejmě není a běžná bude naopak situace, kdy uživatelé budou mít právo jen číst, případně přidávat, ale nikoli měnit a mazat. Rozdíl je však v tom, že tato oprávnění může nastavovat pouze správce.
Základem veřejných složek je veřejný jmenný prostor. Jeho konfigurace může vypadat například takto:
namespace public {
prefix = public/
separator = /
location = maildir:/var/mail/public/Maildir:INDEX=/var/mail/virtual/%d/%n/public
subscriptions = no
list = children
inbox = no
}
Od jmenného pro sdílení se to liší jen málo – typ jmenného prostoru je jiný, jiné je i úložiště (napevno definovaný adresář) a umístění indexů. Nyní je potřeba zajistit, aby měl Dovecot (resp. příslušný uživatel, tedy vmail) přístup k úložišti. Prefix je zde public/, ale není to žádné dogma, může být i jiný, podle potřeby.
V úložišti se pak vytvoří potřebné složky (například pokud potřebujeme složku Abcd, vytvoří se adresář .Abcd a v něm nejlépe hned trojice adresářů new, cur a tmp, všechny samozřejmě se správným souborovým vlastníkem a právy).
V každé složce je pak potřeba vytvořit soubor dovecot-acl s vlastním ACL. Pokud soubor zůstane prázdný, nebude mít přístup nikdo. To ale obvykle nechceme, proto lze definovat potřebná práva – k tomu však musíme znát syntaxi souboru. Tady je jednoduchý příklad:
user=admin@moje.domena lrwstipekxa user=franta@moje.domena lrwstipe authenticated lr
Tento soubor definuje práva tak, že správce (admin@moje.domena) má všechna oprávnění, uživatel franta@moje.domena může jakkoli manipulovat se zprávami (nesmí však nijak manipulovat se složkami) a všichni ověření uživatelé mohou pouze zjišťovat existenci složky a číst obsažené zprávy. Použití authenticated samozřejmě předpokládá povolení této možnosti v konfiguraci – viz výše.
Jak si můžete všimnout, syntaxe se vždy skládá z uvedení subjektu (obecně nebo s identifikací) a masky konkrétních práv tvořené znaky udávajících jednotlivá oprávnění. Přesný význam typů subjektů a písmen používaných v masce najdete v dokumentaci k programu Dovecot.
Stejným způsobem lze v případě potřeby upravovat práva ke sdíleným složkám uživatelů (soubory dovecot-acl jsou stejné) nebo definovat globální ACL. Opět odkazuji na dokumentaci.
Po změně souboru dovecot-acl je vždy potřeba smazat soubor dovecot-acl-list, změny práv totiž mohou mít vliv na to, co se bude předkládat jako seznam složek klientům.
Na závěr ještě jednu důležitou informaci – pokud něco ohledně sdílení nebo ACL nefunguje správně, pak je to velmi pravděpodobně chyba v konfiguraci serveru nebo v implementaci klienta. Až teprve o hodně méně pravděpodobná je chyba serveru. Dobrým vodítkem při hledání chyb je sledování a záznam IMAP komunikace (například pomocí programů tcpdump nebo Wireshark) a porovnávání s tím, co to má podle specifikací dělat.
Příštím dílem se seriál vrátí zase trochu více do oblasti přenosu zpráv. Tématem totiž bude konfigurace záložního poštovního serveru. Na první pohled triviální věc skýtá některá úskalí, která pak (pokud nejsou včas rozpoznána a eliminována) zcela oprávněně vrhají na celou koncepci používání záložních serverů špatné světlo.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.