[Postfixbuch-users] maildrop und Rechteprobleme

[Thomas Schwenski]

Hallo,

meine Fehlermeldungen bei maildrop konnte ich Dank einer schlaflosen 
Nacht nun einer Ursache zuführen.

Bei meinem Setup sind einzelne Postfächer gruppiert.
Einer solchen Gruppe ist ein Systembenutzer und eine -gruppe zugeordnet, 
denen die jeweiligen Dateien und Verzeichnisse im Filesystem gehören.
Die Rechte auf diesen Dateien/Verzeichnissen sind 770.
In den jeweiligen Systemgruppen ist der Systembenutzer vmail Mitglied.

maildrop wird bei mir in der master.cf gemäß Postfix-Howto eingebunden:
 >maildrop  unix  -       n       n       -       -       pipe
 > flags=ODRhu user=vmail argv=/usr/bin/maildrop
 >   -d ${user}@${nexthop} ${extension} ${recipient} ${user} ${nexthop}

Die entsprechenden Optionen in der main.cf sind gesetzt.

Versuche ich nun auf diesem Weg per maildrop eine E-Mail auszuliefern 
erscheint im Log (oder bei direktem Aufruf aus der Shell) die Meldung:

 > terminate called after throwing an instance of 'char const*' 
maildrop: > signal 0x06

Postfix behandelt das als temporären Fehler.

Nach mehreren E-Mails mit Sam Varshavchik letzte Nacht bin ich auf des 
Rätsels Lösung gestossen:

Obwohl der Benutzer vmail auf Grund seiner Mitgliedschaft in der 
Besitzer-Gruppe des Maildirs und der 770-Berechtigungen vollen Zugriff 
hat, liegt hier ein Rechtproblem vor.

Maildrop erwartet, dass UID und GID des Benutzers unter dem es 
ausgeführt wird der UID und GID des Besitzers/der Besitzergruppe 
entsprechen bzw. zumindest denen die courier-authlib zurückliefert.

Ist dies nicht der Fall erscheint der obige Fehler.
Als root funktioniert die Zustellung.
Setzt man für /usr/bin/maildrop das SUID-Flag, verweigert maildrop die 
Zustellung mit der Meldung:

 > You are not a trusted user.

Mir ist bis jetzt noch keine funktionierende Möglichkeit eingefallen, 
die Verzeichnisse durch unterschiedliche 
Besitzverhältnisse/Berechtigungen voneinander abzuschirmen, wie es von 
mir geplant war.
Die einzige Möglichkeit maildrop zum Laufen zu bekommen ist die 
Besitzverhältnisse sämtlichst auf den maildrop ausführenden Benutzer zu 
setzen.
Meines Erachtens steht das aber im kompletten Gegensatz zu 
Couriers/Maildrops Fähigkeit auf die Postfächer virtueller Benutzer mit 
unterschiedlichen UIDs/GIDs zuzugreifen, da dieses Feature ja nicht 
verwendbar ist.

Ich habe Sam Varshavchik deshalb darauf hingewiesen, dass dies' m.E. 
einen Bug darstellt.

Da ich den einzigen Hinweis im Internet auf diese Ursache für die Fehler 
  erst nach meiner eigenen Lösung gefunden habe und es mich mehrere Tage 
und Anläufe gekostet hat ohne eine funktionierende Lösung gefunden zu 
haben, wollte ich das für's Archiv (und für ertragreichere Suchen 
anderer mit demselben Problem) hier nochmal festhalten.

Sollte jemand eine funktionierende Lösung (außer alle Besitzverhätnisse 
auf vmail:vmail zu ändern) kennen, dann würde ich mich natürlich über 
entsprechende Hinweise freuen.

Thomas