web-dev-qa-db-ja.com

後置パラメータdefault_privs

このユーザーのコンテキストで実行されるPerlスクリプトであるdefault_privs=myuserにmain.cfを設定しました。

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権限を持つグループの一部です。コードからわかるように、copyコマンドも出力します。同じコマンドをシェルで実行すると、次のようになります。

su myuser
cp ... ...

ファイルがコピーされます。私の理解では、以前にsu myuserを実行した場合、cpコマンドがPerlスクリプトと同じユーザーコンテキストで実行されているのはどうしてですか。違いはどこですか？

更新：「myuser」が書き込み権限を持っているファイル共有のグループは、このユーザーの補足グループとしてのみ追加されました。これをユーザーのプライマリグループに変更したところ、機能するようになりました。とにかく、この振る舞いは私には非常に奇妙に見えます。

postfixfile-permissionsperluser-permissionsglusterfs
3
markus

OK、少なくとも、この動作が接尾辞で発生した理由について2つの参照があります。しかし、以下の動作の背後にある概念が何であるかはわかりません。考えられる説明の1つは、このスレッドにありました： GID、現在、プライマリ、補足、有効、および実際のグループID？ 。たぶんあなたは nix.SE の専門家のためのさらなる説明を得ることができます。

あなたのケースは、接尾辞のメーリングリストのこれらの2つの質問によって確認されました。 ここではcontent-filterについて および ここではエイリアスからのスクリプトについて 。これらの2つの質問は、あなたの場合と同様に、postfixによって実行されたスクリプトがそのセカンダリグループを持たないことについてでした。説明は次のとおりです。

default_privsを使用してスクリプトを実行するユーザーを指定すると、postfixはプライマリグループ、つまりユーザーのGIDのみを伝送します。ターミナル/ SSHを使用してコマンドを呼び出すと、ログイン時にすべてのセカンダリグループがすでに実行されています。そのため、UNIXは、Perlスクリプトを実行するユーザーがそのフォルダーへの書き込み権限を持つセカンダリグループを持っていることを認識しません。

1つの解決策（プライマリグループの置換を除く）は、 pipe serviceでグループ名を指定することです。 local_transportをオーバーライドすると述べているので、そのpipeをlocal_transportに使用できます。

4
masegaloeh