後綴參數 default_privs

我設置default_privs=myuser了 in 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”是對 glusterfs 文件共享具有 rw 權限的組的一部分。正如您在程式碼中看到的，我還列印出複制命令。如果我採用相同的命令並在 shell 中執行它，例如：

su myuser
cp ... ...

文件被複製。根據我的理解，如果我以前這樣做過，那怎麼可能su myuser，該cp命令與 perl 腳本在相同的使用者上下文中執行。區別在哪裡？

更新：“myuser”具有寫入權限的文件共享組僅作為補充組添加到該使用者。我將其更改為使用者的主要組，現在它可以工作了。無論如何，這種行為對我來說看起來很奇怪。

好的，至少我有兩個參考為什麼會在後綴中發生這種行為。但我不確定以下行為背後的概念是什麼。一個可能的解釋是在這個執行緒中：GID、目前、主要、補充、有效和真實組 ID？. 也許您可以在unix.SE中獲得專家的進一步解釋。

您的案例已通過 postfix 郵件列表中的這兩個問題得到證實。這里關於 content-filter和這里關於 aliases 的腳本。這兩個問題是關於後綴執行的腳本不帶有其輔助組的，與您的情況類似。解釋是：

當你default_privs用來指定執行腳本的使用者時，postfix 只是攜帶了使用者的主要組，即 GID。當您使用終端/SSH 呼叫命令時，所有輔助組在您登錄時已被攜帶。這就是為什麼 UNIX 無法辨識執行 perl 腳本的使用者具有對該文件夾具有寫權限的輔助組。

一種解決方案（除了替換主組）是在管道服務中指定組名。因為您提到您覆蓋了local_transport，所以您可以將其pipe用於 local_transport。

引用自：https://serverfault.com/questions/662487