Ach ja, brauchst Du f�r fetchmail (von root aus gestartet) nicht noch den lokalen Usernamen (f�r "is blabla here")?
Deswegen empfehle ich, fetchmail mit "su - $USER fetchmail" zu starten.
Fetchmail mit .fetchmailrc-Files von Usern w�rde ich nie als root aufrufen, da man dar�ber auch diverse Programme ausf�hren kann, man baut damit ein nettes Scheunentor in s�mtliche Sicherheitskonzepte. ;)
Nein. Bei dem von mir genannten Ansatz gibts ja keine User-fetchmailrcs, sondern
nur eine globale, die aus bestimmten Angaben, die Benutzer machen duerfen,
erzeugt wird. Diese Angaben sind aber auf ein Minimum beschraenkt, so dass man
kaum Unfug anstellen kann.
Zusaetzlich enthaelt das Perlskript, welches diese Angaben einsammelt, einen gewissen Grad an Fehlerbehandlung, so dass abichtliche oder versehentliche Eingaben nicht zum DoS fuehren.
Sicherlich KOENNTEN immer noch Buffer Overflows in Perl oder Fetchmail durch komische Strings in den Dateien oder aber komische Serverangaben oder so aehnlich ausgenutzt werden.
Was Perl angeht, muss ich aber davon ausgehen, dass bei einigermassen vernuenftiger
Ueberpruefung der Eingaben Perl sicher ist, denn sonst kann ich den Rechner
gleich einstampfen.
Fetchmail laeuft als Benutzer/Gruppe fetchmail.
Wenn man sowas in einer Produktionsumgebung mit "echten" Benutzern machen wuerde,
koennte man noch darueber nachdenken, die Userconfigdirs setgid irgendwas zu machen,
so dass das Perlskript zum Sammeln der Angaben auch unpriviligiert laufen koennte.
Dazu sehe ich aber bei mir zuhause unter den gegebenen Umstaenden wenig Anlass. ;)
-- Petr Zavor
-- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/
Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
