Rechte von /etc/dovecot
Hi,
ich habe Dovecot 2.1.9 auf einem Debian6-Server installiert, auf dem
auch ein Apache läuft und Benutzer mit mod_suphp eigene Skripte
erstellen und ausführen können. Mail ausgeliefert wird über Postfix mit
deliver als vmail:mail.
Nun möchte ich nicht, dass normale Nutzer meine dovecot.conf lesen können.
Das Ausführen von
# chmod 640 /etc/dovecot
# chgrp dovecot /etc/dovecot
war nicht erfolgreich, da dann deliver die dovecot.conf nicht mehr lesen
kann.
Im Moment denke ich an eine eigene dovecot-conf Gruppe in der nur die
Benutzer vmail und dovecot sind. Aber evtl. gibts noch eine elegantere
Möglichkeit (z.B. der config-Socket von dovecot?!).
Hat schon jemand Erfahrung mit einer restriktiven Rechtevergabe?
—
Best regards,
Sven Strickroth
PGP key id F5A9D4C4 @ any key-server
-
27. April 2013
-
Sven Strickroth
-
6 Antworten
Am 27.04.2013 18:43, schrieb Sven Strickroth:
Hi,
> ich habe Dovecot 2.1.9 auf einem Debian6-Server installiert, auf dem
> auch ein Apache läuft und Benutzer mit mod_suphp eigene Skripte
> erstellen und ausführen können. Mail ausgeliefert wird über Postfix mit
> deliver als vmail:mail.
Warum deliver?
Geh den Weg über den lmtpd und das Problem hat sich erledigt.
(und das bringt noch viele andere Vorteile. Schneller, performanter,
dynamische Empfängervalidierung und und und).
> Nun möchte ich nicht, dass normale Nutzer meine dovecot.conf lesen können.
Warum nicht? Was soll da schlimmes drin sein!?
> Hat schon jemand Erfahrung mit einer restriktiven Rechtevergabe?
lmtpd nehmen und das Problem ist weg.
(Ich sitze gerade am Dovecot-Buch und habe bis eben gerade ein
90-minütiges Pamphlet GEGEN den deliver geschrieben…)
Peer
—
Heinlein Support GmbH
Schwedter Str. 8/9b, 10119 Berlin
http://www.heinlein-support.de
Tel: 030 / 405051-42
Fax: 030 / 405051-19
Zwangsangaben lt. §35a GmbHG: HRB 93818 B / Amtsgericht
Berlin-Charlottenburg,
Geschäftsführer: Peer Heinlein — Sitz: Berlin
Am 27.04.2013 19:14 schrieb Peer Heinlein:
> Warum deliver?
Historisch gewachsen, hab gerade erst von 1.2 upgegraded (Debian 6).
Zudem wollte ich die +-extensions von Postfix bei Mail-Adressen nutzen.
> Geh den Weg über den lmtpd und das Problem hat sich erledigt.
Muss ich mir mal anschauen.
> (und das bringt noch viele andere Vorteile. Schneller, performanter,
> dynamische Empfängervalidierung und und und).
Dynamische Empfängervalidierung? Postfix prüft doch auch erst, obs die
Adressen gibt, dann prüft deliver doch auch obs die Benutzer gibt und
meldet Fehler über den Returncode an Postfix zurück?!
> Warum nicht? Was soll da schlimmes drin sein!?
An sich steht das nix schlimmes drin, eher ’ne prinzipielle Sache.
Spezielle Quota-Einstellungen müssen ja nicht allen Bekannt werden 😉
—
Best regards,
Sven Strickroth
PGP key id F5A9D4C4 @ any key-server
Am 27.04.2013 19:33, schrieb Sven Strickroth:
> Historisch gewachsen, hab gerade erst von 1.2 upgegraded (Debian 6).
Dann vollende Dein Upgrade und nutze auch die Technik, die dir ein 2.x
bietet. 🙂
> Zudem wollte ich die +-extensions von Postfix bei Mail-Adressen nutzen.
Das geht auch mit LMTP.
Richte in Dovecot den extension-Delimiter ein, dann kann Dovecot damit
selbst umgehen und Postfix reicht das nur durch.
> Dynamische Empfängervalidierung? Postfix prüft doch auch erst, obs die
> Adressen gibt, dann prüft deliver doch auch obs die Benutzer gibt und
> meldet Fehler über den Returncode an Postfix zurück?!
Hmm, ja. Lokal geht sowas, aber man kann von anderen Relays aus nicht
gleich prüfen, wer existiert. Mit LMTP macht’s echt mehr Spaß.
>> Warum nicht? Was soll da schlimmes drin sein!?
>
> An sich steht das nix schlimmes drin, eher ’ne prinzipielle Sache.
> Spezielle Quota-Einstellungen müssen ja nicht allen Bekannt werden 😉
Okay, akzeptiert.
Okay, aber wenn ich jetzt so weiter drüber nachdenke, wirst Du natürlich
trotzdem immer in die Situation kommen, daß Deine Config zu weiten
teilen für Userpresse lesbar sein muß. Schon deshalb, weil auch der
imapd am Ende als vmail-User mit diesen Rechten läuft. LMTP hin oder her
(Du solltest das trotzdem ändern), aber auch deshalb kannst Du das nicht
beliebig zunageln.
Allerdings müßte es doch gehen, diese Datei einem „vmail:root“ zu geben
und dann ein 660 drauf zu machen. Die Dovecot-User-Prozesse sollten dann
doch beliebig rankommen und mit End-Usern und ihrer Gruppe hat das
nichts zu tun?
Kommt jetzt am ende alles sehr drauf an, wie Du Deine User, mit deren
Rechten eingerichtet hast und wo/wie du die Mails speicherst und welche
Rechte/Gruppen da ins Spiel kommen. Da wäre dann auch ein „doveconf -n“
hilfreich.
Peer
—
Heinlein Support GmbH
Schwedter Str. 8/9b, 10119 Berlin
http://www.heinlein-support.de
Tel: 030 / 405051-42
Fax: 030 / 405051-19
Zwangsangaben lt. §35a GmbHG: HRB 93818 B / Amtsgericht
Berlin-Charlottenburg,
Geschäftsführer: Peer Heinlein — Sitz: Berlin
Am 27.04.2013 19:40 schrieb Peer Heinlein:
> Okay, aber wenn ich jetzt so weiter drüber nachdenke, wirst Du natürlich
> trotzdem immer in die Situation kommen, daß Deine Config zu weiten
> teilen für Userpresse lesbar sein muß. Schon deshalb, weil auch der
> imapd am Ende als vmail-User mit diesen Rechten läuft. LMTP hin oder her
> (Du solltest das trotzdem ändern), aber auch deshalb kannst Du das nicht
> beliebig zunageln.
Das deckt sich nicht mit meinen bisherigen Erfahrungen.
Bei chgrp dovecot /etc/dovecot und chmod 750 /etc/dovecot lief alles,
bis auf deliver (der demnächst durch lmtp ersetzt wird). Der
imap-Prozess (auch der einzige, der als vmail läuft) hat sich nie über
fehlende Rechte beschwert (bekommt der nicht eh alle Einstellungen über
Environment-Variablen übergeben?).
> Allerdings müßte es doch gehen, diese Datei einem „vmail:root“ zu geben
> und dann ein 660 drauf zu machen. Die Dovecot-User-Prozesse sollten dann
> doch beliebig rankommen und mit End-Usern und ihrer Gruppe hat das
> nichts zu tun?
Schreibrechte für vmail? Das ist nicht nötig. Leserechte für die Gruppe
root mag für die dovecot.conf reichen, wenn man aber schon /etc/dovecot
„dicht machen“ will reicht das nicht, da z.B. der dict-Service als
dovecot:dovecot läuft und dann die dicts nicht mehr lesen kann.
> Kommt jetzt am ende alles sehr drauf an, wie Du Deine User, mit deren
> Rechten eingerichtet hast und wo/wie du die Mails speicherst und welche
> Rechte/Gruppen da ins Spiel kommen. Da wäre dann auch ein „doveconf -n“
> hilfreich.
Die Mail-Benutzer gibts nur virtuell. Die Benutzer werden über die
userdb alle auf vmail:mail gemappt und das Homedir wird auf
/var/spool/vmail/%d/%n festgelegt. /var/spool/vmail/ kann nur von vmail
gelesen/geschrieben werden. Zur Abschottung gegen die User reichts also,
wenn die Konfig. nicht welt-lesbar ist.
—
Best regards,
Sven Strickroth
PGP key id F5A9D4C4 @ any key-server
Am 27.04.2013 19:40 schrieb Peer Heinlein:
> Dann vollende Dein Upgrade und nutze auch die Technik, die dir ein 2.x
> bietet. 🙂
Fertig. Danke für den Tipp!
Dann noch ein kurzes Update:
# chgrp dovecot /etc/dovecot
# chmod 750 /etc/dovecot
funktioniert mit lmtpd.
—
Best regards,
Sven Strickroth
PGP key id F5A9D4C4 @ any key-server
On 04/27/2013 07:40 PM Peer Heinlein wrote:
> Am 27.04.2013 19:33, schrieb Sven Strickroth:
>> Dynamische Empfängervalidierung? Postfix prüft doch auch erst, obs die
>> Adressen gibt, dann prüft deliver doch auch obs die Benutzer gibt und
>> meldet Fehler über den Returncode an Postfix zurück?!
>
> Hmm, ja. Lokal geht sowas, aber man kann von anderen Relays aus nicht
> gleich prüfen, wer existiert. Mit LMTP macht’s echt mehr Spaß.
Dovecot >= v2.1.0 kann Postfix, per tcp_map(5), die vorhandenen Accounts
zu Verfügung stellen
.
Das funktioniert aber nur dann zuverlässig, wenn man keine Aliases hat.
Daher führt wohl kein Weg daran vorbei, seine $relay_domains und
$relay_recipient_maps auf die beteiligten MXe zu verteilen.
Gruß
Pascal
—
The trapper recommends today: c01dcofe.1311722@localdomain.org