parâmetro postfix default_privs

Question

Eu defini default_privs=myuser em main.cf , que é um script perl, executado no contexto deste usuário.

No script perl, adicionei alguns erros para imprimir o usuário:

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

Se o script for acionado por um e-mail recebido, posso ver que o script está sendo executado no contexto do usuário "myuser".

Mais tarde, no script, tento copiar um arquivo. Eu uso backticks para obter a saída de STDOUT e STDERR:

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

Mas isso me dá:

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

O usuário "myuser" faz parte de um grupo que possui permissões rw no compartilhamento de arquivos glusterfs. Como você pode ver no código, eu também imprimo o comando copy. Se eu pegar o mesmo comando e executá-lo em um shell, como:

su myuser
cp ... ...

o arquivo é copiado. Como isso pode ser, no meu entender, se eu fizer su myuser antes, o comando cp estará executando no mesmo contexto de usuário que o script perl. Onde está a diferença?

ATUALIZAÇÃO: O grupo do compartilhamento de arquivos que o 'myuser' tem permissões de gravação foi adicionado apenas como grupo suplementar a este usuário. Eu mudei isso para o grupo principal do usuário, e agora funciona. De qualquer forma, esse comportamento parece muito estranho para mim.

    

Answer 1

OK, pelo menos eu tenho duas referências porque esse comportamento aconteceu no postfix. Mas não tenho certeza qual é o conceito por trás do comportamento. Uma possível explicação foi neste tópico: GID, IDs de grupo atual, primário, suplementar, efetivo e real? . Talvez você possa obter mais explicações para os especialistas em unix.SE .

Seu caso foi confirmado por estas duas perguntas na lista de discussão postfix. Aqui, sobre o filtro de conteúdo e aqui sobre script de aliases . Essas duas perguntas eram sobre um script que executado pelo postfix não carrega seu grupo secundário, semelhante ao seu caso. A explicação é:

When you use default_privs to specify the user that execute the script, postfix just carried the primary group i.e. GID of the user. When you invoke command with terminal/SSH, the all secondary group(s) was already carried when you are logged-in. So that's why UNIX doesn't recognize that user who execute perl script has secondary group who has write permission to that folder.

Uma solução (exceto substituir o grupo primário) está especificando o nome do grupo no serviço pipe . Porque você mencionou que você substitui o local_transport , então você pode usar esse pipe para local_transport.