Am Dienstag, 13. Juni 2006 10:34 schrieb Kyek, Andreas, VF-DE:
Roland M. Kruggel wrote:
Am Dienstag, 13. Juni 2006 10:05 schrieb Oliver Meißner-Knippschild:
Roland M. Kruggel wrote on Tue, 13 Jun 2006 09:43:25 +0200:
Schon klar, aber wie sieht's auf nem Server aus, der für alle User die Mails abholen soll? Da in der fetchmailrc ja auch die Kennwörter stehen ist das eine ziemlich heikle Geschichte...
Nein. Die /etc/fetchmailrc gehört dem user fetchmail und _NUR_ der hat zugriff darauf. chmod 600 /etc/fetchmailrc. Alle anderen können noch nicht mal lesen.
Und ganz genau _das_ ist ja das Problem an der Sache. Wenn jetzt ein User sein Kennwort ändern möchte (was wirklich sehr sehr lobenswert ist!), dann muss er dazu erstmal zum fetchmail-user werden um die Datei zu verändern. Dann hat er allerdings auch Zugriff auf die Kennwörter aller anderen User und deren Postfächer.
Ich glaube du bist irgendwie auf dem falschen Dampfer :)
Die User habe nichts mit fetchmail zu tun. Du als Admin stellst einmal fetchmail ein und holst _ALLE_ Postfächer ab und verteilst sie an die einzelnen User. Der User hat nur noch seinen Mailclient, mehr nicht.
Ja und nein. Theoretisch hast Du zwar Recht, aber dann hat Oliver insofern Recht als das _kein_ Benutzer sein Mailpasswort z.B. bei web.de ändern kann ohne das fetchmail seine Mails nicht mehr holen kann. Denn das password steht in der fetchmailrc.
Zwei Anmerkungen dazu: 1. Problematisch bei allen diesen Änderungen an der fetchmailrc ist, das fetchmail ganz leise stirbt sollte sich ein Syntaxfehler in die fetchmailrc eingeschlichen haben. Und das passiert schneller, als man denkt. Daher das immer beachten, wenn man zu 2. kommt.
2. Lösungsidee "man fetchmail" sagt, das man bei "-f pathname" auch "-f -" sagen kann; dann erwartet fetchmail die fetchmailrc via stdin. So liesse sich ein kleines Skript bauen, das den header und die einzelnen fetchmailrc's der Reihe nach auf stdout ausgibt und dann so dynamisch eine fetchmailrc konstruiert.
Ich würde es NICHT so machen.
Besser wäre es IMO:
fetchmail läuft mit einer /etc/fetchmailrc wie gehabt. root hat einen cronjob, der periodisch eine definerte Datei im User-Home scannt und dort die Passwortänderungen mitbekommt. root baut dann die neue fetchmailrc.
Das _könnte_ man beliebig ausbauen: User können nur passwort ändern; user können auch neue "maildrops" angegeben, indem einfach in der Datei die Kombination von "server, user, passwort" angegeben ist etc. Und die Liste der zu scannenden User-Homes kann man via zweiter Konfigdatei dem Skript zufüttern, ...
Fetchmai kann ja mehrere user mit einer fetchmailrc bedienen. Wenn du Beispiele Brauchst, sag bescheid.
Das ist nicht das Problem; ich denke das kann er.
Ich möchte das jetzt bei uns Privat einsetzen, und meine Frau soll schon das Gefühl dafür bekommen, dass Benutzernamen und vor allem Kennwörter so wirklich absolut _niemanden_ etwas angehen (noch nicht mal den zuständigen Admin, denn der hat die Möglichkeit Kennwörter zurückzusetzen, wenn es sein muss!!!). In diese Richtung versuche ich schon sehr verzweifelt unsere Kunden zu erziehen... Da mache ich dann auch zuhause keine Ausnahme!
Löblich, aber in diesem Fall unnötig.
Nee, leider nicht. Aber meine Frau z.B. will die Mails gar nicht bei GMX, Web.de selber abholen (können); sie will nur ihr kmail starten und die Mails haben gefälligst da zu sein. Sie hat sich diesen Mail-Account nicht einmal selber eingerichtet.
Ebend. Deshalb bin ich ja auch für eine /etc/fetchmailrc und nicht für $HOME/.fetchmailrc. WÈNN der user mal das Passwort bei gmx, web.de etc. ändert, dann kann der Admin kurz eingreife und alles läuft wieder.
Aber das muss jeder selber entscheiden.
ACK -- cu Roland Kruggel mailto: rk.liste at bbf7.de System: Intel, Debian etch, 2.6.16.16, xfce4 KDE 3.5 -- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-linux-unsubscribe@suse.com Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-linux-help@suse.com