3 votes

paramètre postfix default_privs

J'ai mis default_privs=myuser en main.cf qui est un script perl, exécuté dans le contexte de cet utilisateur.

Dans le perl script j'ai ajouté un débogage pour imprimer l'utilisateur :

my $exec_username = $ENV{LOGNAME} || $ENV{USER} || getpwuid($<);
$logger->info("Script is running in context of user:".$exec_username);

Si le script est déclenché par un courriel entrant, je peux voir que le script s'exécute dans le contexte de l'utilisateur "myuser".

Plus tard dans le script, j'essaie de copier un fichier. J'utilise des backticks pour obtenir la sortie de STDOUT et STDERR :

my $copycmd = "cp -f -v '".$final_tiff."' '".$fax_file_name."'";
$logger->info("Copy command: ".$copycmd);
my $copylog=`$copycmd 2>&1`;
$logger->info($copylog);

Mais ça me donne :

cp: cannot create regular file ... : Permission denied

L'utilisateur "myuser" fait partie d'un groupe qui a des permissions rw sur le partage de fichiers glusterfs. Comme vous pouvez le voir dans le code, j'imprime également la commande de copie. Si je prends la même commande et l'exécute dans un Shell, comme :

su myuser
cp ... ...

le fichier est copié. Comment cela peut-il être, pour ma compréhension, si je fais su myuser avant, le cp s'exécute dans le même contexte utilisateur que la commande perl script. Où est la différence ?

MISE À JOUR : Le groupe du partage de fichiers dans lequel 'myuser' a des droits d'écriture n'a été ajouté que comme groupe supplémentaire à cet utilisateur. Je l'ai changé en groupe principal de l'utilisateur, et maintenant cela fonctionne. Quoi qu'il en soit, ce comportement me semble très étrange.

0 votes

Quelle méthode utilisez-vous pour acheminer le courrier électronique vers script ? méthode des alias ? méthode du transport ?

0 votes

J'utilise des alias et le transport local.

0 votes

a des permissions rw sur le partage de fichiers --> Vous voulez dire un partage de fichiers comme NFS ?

4voto

masegaloeh Points 17760

OK, au moins j'ai deux références pourquoi ce comportement s'est produit dans postfix. Mais je ne suis pas sûr du concept derrière ce comportement. Une explication possible était dans ce fil : GID, IDs de groupe actuels, primaires, supplémentaires, effectifs et réels ? . Vous pouvez peut-être obtenir des explications supplémentaires auprès des experts en unix.SE .

Votre cas a été confirmé par ces deux questions dans la mailing-list de postfix. A propos de content-filter y ici à propos de script d'alias . Ces deux questions concernaient un script qui exécuté par postfix ne porte pas son groupe secondaire, similaire à votre cas. L'explication est la suivante :

Lorsque vous utilisez default_privs pour spécifier l'utilisateur qui exécute le script, postfix a juste porté le groupe primaire c'est-à-dire le GID de l'utilisateur. Lorsque vous invoquez une commande avec terminal/SSH, le(s) groupe(s) secondaire(s) ont déjà été transportés lorsque vous êtes connecté. C'est pourquoi UNIX ne reconnaît pas que l'utilisateur qui exécute perl script a un groupe secondaire qui a le droit d'écrire sur ce dossier.

Une solution (sauf pour remplacer le groupe primaire) est de spécifier le nom du groupe dans le champ tuyau service. Parce que vous mentionnez que vous remplacez le local_transport alors vous pouvez l'utiliser pipe pour local_transport.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X