постфиксный параметр default_privs
Я установил default_privs=myuser в main.cf, который является сценарием жемчуга, выполняемым в контексте этого пользователя.
В сценарии жемчуга я добавил некоторую отладку для распечатывания пользователя:
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 команда работает в том же пользовательском контексте, чем сценарий жемчуга. Где различие?
ОБНОВЛЕНИЕ: группа fileshare, где 'myuser' имеет полномочия записи, была только добавлена как дополнительная группа к этому пользователю. Я изменил это на основную группу пользователя, и теперь она работает. Так или иначе это поведение выглядит очень странным для меня.
Хорошо, по крайней мере, у меня есть две ссылки, почему такое поведение произошло в postfix. Но я не уверен, что за концепция ниже поведения. Одно возможное объяснение было в этой ветке: GID, текущие, основные, дополнительные, эффективные и реальные идентификаторы группы? . Возможно, вы сможете получить дальнейшее объяснение для экспертов по unix.SE .
Эти два вопроса подтвердили ваш случай в списке рассылки postfix. Здесь про контент-фильтр и здесь про скрипт из алиасов . Эти два вопроса касались сценария, который выполняется postfix, но не имеет вторичной группы, как и в вашем случае. Объяснение таково:
Когда вы используете
default_privs, чтобы указать пользователя, выполняющего сценарий, postfix просто переносил первичную группу, то есть GID пользователя. Когда вы вызываете команду с помощью терминала / SSH, все вторичные группы уже были перенесены, когда вы вошли в систему. Вот почему UNIX не распознает, что у пользователя, выполняющего сценарий perl, есть вторичная группа, у которой есть разрешение на запись в эту папку.
Одно из решений (кроме замены первичной группы) - указание имени группы в службе pipe . Поскольку вы упомянули, что переопределяете local_transport , тогда вы можете использовать этот канал для local_transport.