Re: [sympa-fr] question UID/GID

[Patrick Proniewski <adresse@cachée>]

Bonjour,

On 5 mars 2015, at 11:26, Philippe Aepli <adresse@cachée> wrote:

> 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).


Merci pour ces recherches complémentaires. J'avais aussi fait quelques grep 
dans le code, mais cela ne m'a pas vraiment parlé, puisque je ne connais pas 
PERL.


> 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.


J'ai cru que le bloc "getgrnam(Sympa::Constants::GROUP)" allait simplement 
lire la constante issue de la lecture de /etc/passwd...
Ça en dit long sur mon niveau en PERL ;)


> 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 ?


Ce n'est pas possible, car en réalité le groupe principal de procmail n'est 
pas la cible ici. Il y a dans le code de procmail une liste des groupes 
"autorisés" indiqués par la page man de procmail(1) :

       When  in  explicit delivery mode, procmail will generate a leading 
‘From ’
       line if none is present.  If one is already present procmail will 
leave it
       intact.   If  procmail  is  not  invoked with one of the following 
user or
       group ids: root, daemon, uucp, mail, x400, network, list, slist, lists 
 or
       news, but still has to generate or accept a new ‘From ’ line, it will 
gen-
       erate an additional ‘>From ’ line to help distinguish fake mails.

J'ai donc droit de faire tourner Sympa avec les GID root, daemon, uucp, mail, 
x400, network, list, slist, lists ou news. Si je ne fais pas cela, alors 
procmail ajoute le ">From " qui fait que Sympa rejette le message.

Je ne souhaite pas modifier le code de procmail pour changer ce comportement, 
cela poserait des problèmes de maintenabilité.


> 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>).


Le scénario me semble bon, hormis la modification de bin/Sympa/Constants.pm 
que je n'aurai jamais trouvé tout seul, cela ressemble fort à ce que j'avais 
en tête. J'aurai malgré-tout conservé le groupe sympa pour le cas où.


> 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


Peut être que nous ferons ce changement dans un second temps, l'autre 
possibilité est de faire tourner un Apache-ITK, mais j'aime bien en général 
gardé des utilisateurs différents pour différents process.

J'espère pouvoir tester la migration vers le groupe "mail" rapidement.

Encore merci pour les informations précieuses,

Patrick PRONIEWSKI
-- 
Responsable pôle Opérations - DSI - Université Lumière Lyon 2
Responsable Sécurité des Systèmes d'Information