On Thu, 17 Oct 2002 15:36:37 +0200
Pascal Bleser <[EMAIL PROTECTED]> wrote:
> ...
> > J'ai juste un petit souci c'est qu'une autre doc dit aussi que fetchmail doit
>tourner sous un compte avec des restrictions de droit pour des raisons de sécurité.
> > Et le mien il tourne en root???
> >
> > root 301 0.0 0.3 1916 888 ? S 10:19 0:00 /usr/bin/fetchmail
>-f /etc/fetchmailrc
> > C'est normal ça?
>
> En fait, fetchmail *en démon* doit tourner sous root car il peut downloader des
>mails et les stoquer
> dans des boîtes différentes de la sienne, ce qui signifie dans un fichier mbox
>appartennant à un
> autre utilisateur (/var/spool/mail/...)
>
> Je m'explique: si dans /etc/fetchmailrc tu as qqe chose comme:
>
> poll pop.skynet.be proto pop3 user "machin" pass "brol" is "bazar" here
> ^^^^^^^^^^^^^^^
> cela signifie qu'il va rechercher les mails à l'adresse indiquée et va les stoquer
>dans la boîte
> locale (mbox) de l'utilisateur (local) "bazar" => /var/spool/mail/bazar
>
> Or ce fichier mbox appartient (owner) à l'utilisateur "bazar", donc il faut qu'il
>soit root pour
> pouvoir écrire dans ce fichier (/var/spool/mail/bazar)
Dans la doc que j'ai lue, ils disent que c'est pas sécurisé de cette façon.
> Note qu'un workaround très simple serait de créer
> - un user non privilégié sous lequel faire tourner fetchmail, p.ex. "fetchml"
>(utilisateur
> verrouillé = pas de mot de passe + shell = /bin/false)
> - un groupe p.ex. "mboxadm" et d'y mettre cet utilisateur (uniquement)
> - changer les permissions des fichiers /var/spool/mail/* en mettant le "owner group"
>à "mboxadm"
> ainsi que les droits du "owner group" à rw-
> - mettre le "owner group" de /var/spool/mail à "mboxadm" également, ainsi que d'y
>ajouter le "sticky
> bit" sur le "owner group" afin que le "owner group" de tous les fichiers s'y
>trouvant soient
> automatiquement mis à "mboxadm"
> - modifier le script /etc/init.d/fetchmail afin d'y faire un "su" sur cet utilisateur
D'après le peut que j'en sait, je préfère ta deuxième solution.
Et c'est bien comme ça qu'est rédigé mon fichier après réinstalation de fetchmail:
lorsqu'il stop :
su "--command=${DAEMON} --quit" ${RUNUSER}
Var de la chaine lorsequ'il démare:
START="--start --quiet --exec ${DAEMON} --user ${RUNUSER} --startas /bin/su --"
Bien sûr :
RUNUSER=fetchmail
Petite question, c'est quoi la dif entre $START et ${START} ?
>
> Bref:
>
> groupadd mboxadm
> useradd -g mboxadm -d /tmp -s /bin/false -c "Daemon user for fetchmail" -r fetchml
> chgrp -R mboxadm /var/spool/mail
> chmod g=rw /var/spool/mail/*
> chmod g+s /var/spool/mail
J'ai ça aussi, c'est quoi la permission "s"?
L'install m'a bien créé un user fetchmail.
Sauf que J'ai un shell.
fetchmail:x:numero:numero::/var/run/fetchmail:/bin/sh
> Les seuls problèmes qui subsistent:
> - les fichiers dans /var/spool/mail/ sont créés et effacés dynamiquement par p.ex.
>sendmail ou
> fetchmail ou autre client mail (lorsque mbox vide => effacée): lorsqu'ils sont
>créés, ils le sont en
> mode rw- --- --- (0600) et il n'y a aucun moyen d'influencer cela car c'est le soft
>qui crée le
> fichier mbox qui contrôle cela
> - aucune idée sur la Debian, mais sur la grande majorité des distributions tu as des
>scripts de
> surveillance qui vérifient les droits d'accès de beaucoup de fichiers en comparant
>par rapport à une
> liste (ou la DB RPM) et qui sont éxécutés pérodiquement - exemple sur la SuSE:
> /etc/permissions.d/sendmail -> /var/spool/mail root.root 1777
> Il faut donc penser à modifier le(s) fichier(s) approprié(s) afin que les droits
>d'accès ne soient
> pas tout le temps remis aux défauts.
>
> Voilà voilà ;-)
Merci pour ces explications.
Benoît
_______________________________________________________
Linux Mailing List - http://www.unixtech.be
Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux
Archives: http://www.mail-archive.com/linux@;lists.unixtech.be
IRC: efnet.skynet.be:6667 - #unixtech
