Я установил default_privs=myuser в main.cf, который представляет собой сценарий Perl, выполняемый в контексте этого пользователя.
В скрипте perl я добавил отладку, чтобы распечатать пользователя:
my $exec_username = $ENV{LOGNAME} || $ENV{USER} || getpwuid($<);
$logger->info("Script is running in context of user:".$exec_username);
Если сценарий запускается входящим электронным письмом, я вижу, что сценарий выполняется в контексте пользователя «myuser».
Позже в сценарии я пытаюсь скопировать файл. Я использую обратные кавычки, чтобы получить вывод STDOUT и STDERR:
my $copycmd = "cp -f -v '".$final_tiff."' '".$fax_file_name."'";
$logger->info("Copy command: ".$copycmd);
my $copylog=`$copycmd 2>&1`;
$logger->info($copylog);
Но это дает мне:
cp: cannot create regular file ... : Permission denied
Пользователь «myuser» является частью группы, имеющей разрешения rw на файловом ресурсе glusterfs. Как вы можете видеть в коде, я также распечатал команду копирования. Если я возьму ту же команду и запустил ее в оболочке, например:
su myuser
cp ... ...
файл скопирован. Как это может быть, насколько я понимаю, если я su myuser перед cp команда выполняется в том же пользовательском контексте, что и сценарий perl. В чем разница?
ОБНОВЛЕНИЕ: группа файлового ресурса, у которого 'myuser' есть права на запись, была добавлена только как дополнительная группа для этого пользователя. Я изменил это на основную группу пользователя, и теперь она работает. Во всяком случае, мне такое поведение кажется очень странным.
Хорошо, по крайней мере, у меня есть две ссылки, почему такое поведение произошло в postfix. Но я не уверен, что за концепция ниже поведения. Одно из возможных объяснений было в этой ветке: GID, текущий, основной, дополнительный, эффективный и реальный идентификаторы группы?. Может быть, вы сможете получить дальнейшее объяснение для экспертов в unix.SE.
Ваш случай был подтвержден этими двумя вопросами в списке рассылки postfix. Вот про контент-фильтр и вот про скрипт из псевдонимов. Эти два вопроса касались сценария, который выполняется postfix, но не имеет своей вторичной группы, как и в вашем случае. Объяснение таково:
Когда вы используете
default_privsчтобы указать пользователя, выполняющего скрипт, postfix просто нес основную группу, то есть GID пользователя. Когда вы вызываете команду с помощью терминала / SSH, все вторичные группы уже были перенесены, когда вы вошли в систему. Вот почему UNIX не распознает, что у пользователя, выполняющего сценарий perl, есть вторичная группа, у которой есть разрешение на запись в эту папку.
Одно из решений (кроме замены основной группы) - это указать имя группы в труба служба. Поскольку вы упомянули, что переопределяете local_transport, тогда вы можете использовать это pipe для local_transport.