RE: [sympa-fr] question UID/GID

[Philippe Aepli <adresse@cachée>]

Bonjour,

Un de mes collègues utilise une RedHat et effectivement le résultat de 
l'option
-g de usermod n'est pas identique entre une Debian et une RedHat, au temps 
pour
moi.

Pour revenir au problème, j'ai été regardé de plus près le code de sympa.pl et
voici quelques lignes intéressantes qui devraient répondre à votre question:

    # Set the UserID & GroupID for the process
    $( = $) = (getgrnam(Sympa::Constants::GROUP))[2];
    $< = $> = (getpwnam(Sympa::Constants::USER))[2];

    ## Required on FreeBSD to change ALL IDs(effective UID + real UID + saved 
UID)
    &POSIX::setuid((getpwnam(Sympa::Constants::USER))[2]);
    &POSIX::setgid((getgrnam(Sympa::Constants::GROUP))[2]);

    ## Check if the UID has correctly been set (usefull on OS X)
    unless (($( == (getgrnam(Sympa::Constants::GROUP))[2]) && ($< == 
(getpwnam(Sympa::Constants::USER))[2])) {
        &fatal_err("Failed to change process userID and groupID. Note that on 
some OS Perl scripts can't change their real UID. In such circumstances Sympa 
should be run via SUDO.");
    }

Petite remarque, $(, $), $< et $> sont des variables internes de perl et qui
correspondent respectivement au gid, egid, uid et euid du processus
(cf.: http://www.perlmonks.org/?node=perlvar).

Comme vous pouvez le voir, ces valeurs sont définies dans le module Constants 
et
sont statiques. Aussi, si l'utilisateur devant exécuter le programme sympa
change de groupe, il faudra aussi le faire savoir à sympa en modifiant ce 
module.

Si j'ai bien compris votre objectif c'est de faire coïncider le groupe
principale de procmail et de sympa. Si jamais le changement de groupe 
principal
pour sympa est trop compliqué, avez-vous regardé du côté de procmail.

Pourquoi ne pas changer le gid/egid de procmail ?

Si vous voulez toujours utiliser un autre groupe pour l'exécution de sympa,
je vous propose le scénario suivant:
- Arrêt du serveur apache dédié à sympa
- Arrêt des services de sympa (sympa, bulk, ...)
- Changement de groupe principal pour l'utilisateur sympa, le groupe sympa 
n'est
  plus nécessaire.
  La commande id devrait retourner quelques chose comme cela:
    uid=59689(sympa) gid=12(mail) groups=12(mail)
- Changement de groupe pour les fichiers se trouvant dans le dossier personnel
  de l'utilisateur sympa.
- Changement de groupe pour le fichier d'alias, dans mon installation se 
fichier
  se situe dans /etc/mail/sympa_aliases.
- Modification de la ligne "use constant GROUP   => 'sympa';" du module
  Constants (<home_sympa>/bin/Sympa/Constants.pm).
- Redémarré les services sympa, puis apache

N'ayant jamais fait ce genre de modifications, j'espère que je n'ai rien 
oublié.
Par contre, il faudra vous assurer que plus aucun fichiers n'appartiennent au
groupe sympa à l'aide de la commande find (find <path> -group <group_name>).

Vous savez qu'il n'est pas nécessaire d'utiliser le "sticky bit" si vous avez
dédié apache à votre service sympa.
Vous pouvez spécifier à l'aide de variables d'environnement l'uid et le gid
d'apache. Pour ma Debian le fichier est /etc/apache2/envvars.
Il faudra ensuite faire quelques modification sur le système de fichier en
adaptant l'uid et le gid des fichiers et dossiers suivant:
    /var/lock/apache2
    /var/lib/apache2/fcgid

Salutations.

---

Philippe AEPLI              Email: adresse@cachée
Université de Genève        Tél: +41 22 379 72 86
Division STIC               Mob: +41 79 280 20 24
Rue du Général-Dufour, 24   Fax: +41 22 379 79 86
1204 Genève

> -----Message d'origine-----
> De : Patrick Proniewski [mailto:adresse@cachée]
> Envoyé : lundi 2 mars 2015 16:34
> À : Philippe Aepli
> Cc : adresse@cachée
> Objet : Re: [sympa-fr] question UID/GID
> 
> Bonjour,
> 
> On 2 mars 2015, at 14:54, Philippe Aepli <adresse@cachée>
> wrote:
> 
> > Je pense que votre problème viens du fait que vous avez utilisé
> l'option -g (g minuscule).
> >
> > Cette option modifie le groupe principal d'un utilisateur et change
> le groupe pour tous les fichiers se trouvant dans le "home" répertoire
> de l'utilisateur.
> 
> Pas chez moi (RHEL 6). Les fichiers présents dans le home ne changent
> pas de groupe :
> 
> # grep sympa /etc/passwd
> sympa:x:59689:59689:logiciel Sympa:/home/sympa:/bin/bash
> # id sympa
> uid=59689(sympa) gid=59689(sympa) groups=59689(sympa)
> # ls -l /home/sympa/
> ...
> drwxr-xr-x. 423 sympa sympa 36864 Mar  2 12:30 bounce
> ...
> 
> # usermod -g mail sympa
> # id sympa
> uid=59689(sympa) gid=12(mail) groups=12(mail),59689(sympa)
> # ls -l /home/sympa/
> ...
> drwxr-xr-x. 423 sympa sympa 36864 Mar  2 12:30 bounce
> ...
> 
> 
> 
> > Si vous faites cette intervention sans avoir préalablement arrêter
> les processus de Sympa, et que vos fichier se trouvent dans le "home"
> répertoire de votre utilisateur, vous risquez d'avoir quelques soucis
> ...
> 
> 
> Je n'ai pas l'impression que le problème se situe à cet endroit (droits
> de fichiers), par ailleurs, les droits restent bons pour le user, cela
> ne devrait pas causer de blocage. Le seul blocage potentiel à ce niveau
> serait du à un process éxécuté avec une autre uid que sympa, mais avec
> le gid sympa et ayant besoin d'écrire dans des fichiers/répertoires
> appartenant à sympa:mail. Je n'ai pas constaté ce cas de figure.
> Pour moi le souci vient plutôt de l'exécution d'une commande
> (sympa[15488]: Failed to change process userID and groupID)
> 
> 
> > Par contre, pour ajouter un groupe à votre utilisateur, il faut
> utiliser l'option -G (g majuscule). Cela ne modifier pas le
> propriétaire des fichiers.
> 
> Cela ne peut pas fonctionner, le process n'est pas lancé avec un groupe
> secondaire, il est lancé avec le gid du groupe principal, donc c'est
> bien celui-ci qu'il faut modifier (j'avais essayé quand même avant de
> m'attaquer au changement de gid).
> 
> 
> > Quoi qu'il en soit, avant de modifier les groupes de votre
> utilisateur, il faudra arrêter Sympa, puis le redémarrer après la
> modification.
> 
> C'est une sage précaution, mais tout ce que je vais probablement
> obtenir ce sont des symptômes identiques (sympa[15488]: Failed to
> change process userID and groupID). Il y a quelque chose qui m'échappe
> : est-ce que c'est le wrapper apache qui tente de lancer un process
> avec un autre gid et qui trébuche ? est-ce que c'est un tout autre
> process ?
> 
> 
> > Si votre serveur apache s'exécute sous l'utilisateur sympa, il faudra
> aussi modifié l'environnement d'exécution. Pour une Debian Wheezy, le
> fichier se nomme: /etc/apache2/envvars.
> 
> 
> Notre apache tourne avec son user par défaut, par contre le wrapper
> fcgi est en suid+sgid :
> 
> -rwsr-sr-x. 1 sympa sympa   8768 Jun 25  2013 wwsympa-wrapper.fcgi
> 
> Alors c'est peut être un problème si il tente d'exécuter un process
> sous sympa:mail alors qu'il est lancé lui-même en sympa:sympa.
> Mais pourquoi essayerait-il de lancer le process sympa ? (celui qui
> génère l'erreur dans les log) Et pourquoi tenterait-il de le faire en
> sympa:mail ?
> 
> Je vais creuser ici aussi, au moins tenter de faire les choses bien
> carrées, à un moment de faible affluence :
> 
> - tout couper
> - usermod -g mail sympa
> - chgrp mail wwsympa-wrapper.fcgi
> - chmod g+s wwsympa-wrapper.fcgi
> - tout relancer
> 
> Mais je reste dubitatif, j'ai vraiment l'impression que quelque chose
> m'a échappé, et ce sera pas évident de mettre le doigt dessus tant que
> je ne pourrai pas trouver qui a lancé les process sympa qui ont généré
> les erreurs dans les logs.
> 
> Patrick PRONIEWSKI
> --
> Responsable pôle Opérations - DSI - Université Lumière Lyon 2
> Responsable Sécurité des Systèmes d'Information