SELinux:読み取り権限を付与する方法は?

SELinux:読み取り権限を付与する方法は?

このサービスにはsystemd次のプロパティがありますPIDFile

PIDFile=/home/john/.pm2/pm2.pid

ファイルがこのディレクトリにあると予想できます/run。残念ながらそのような状態なので、直接変更することはできません(しかし、私は努力しています。)。

したがって、サービスを開始すると、このエラーが発生します。

SELinux is preventing systemd from read access on the file pm2.pid.

(私が考える)関連情報は次のとおりです。

Source Context                system_u:system_r:init_t:s0
Target Context                system_u:object_r:user_home_t:s0

でターゲットコンテキストを更新したいと思いますchcon。 3番目のビット(別名タイプ)を更新する必要があるようですが、何を設定するのかわかりません。

エラーが消えるようにPIDファイルのセキュリティコンテキストをどのように変更しますか?

答え1

新しいSELinuxルールを必要としない他のオプションを追加してください。

systemd起動したファイルを編集pm2し、PIDFileの代替場所を指定しますpm2。 2 つの変更を適用する必要があります。 1つはpm2PIDFileを保存する場所を指定し、もう1つはPIDFilesystemdを見つける場所を指定することです。既存のPIDFile行を次の2行に置き換えます。

Environment=PM2_PID_FILE_PATH=/run/pm2.pid
PIDFile=/run/pm2.pid

新しいSELinuxルールを追加する権限がある場合は、systemdこのファイルを編集する権限も必要です。

答え2

まだ把握していないため、SELinuxはブロックしますpm2が、正しく記録しません(すべてのログを表示するように設定を変更した後でも)。したがってaudit2allow

半日を過ごした後、ついに私の解決策は、目的のユーザーpm2として実行されるカスタム.shを作成し、その.shを実行するサービスを作成することでした。

次のタスクはrootユーザーとして完了します。

  1. ディレクトリの作成mkdir /usr/bin/pm2-startup
  2. nano pm2-startup.sh次の内容でスクリプトファイルを作成します。
    #!/bin/bash
    runuser -l [insert desired username here] -c 'pm2 resurrect'
    
  3. nano /etc/systemd/system/pm2.service次の内容でサービスファイルを作成します。
    [Unit]
    Description=Resurrect PM2 as [desired username]
    After=network.target
    
    [Service]
    Type=simple
    ExecStart=/usr/bin/pm2-startup/pm2_startup.sh
    TimeoutStartSec=0
    
    [Install]
    WantedBy=default.target
    
  4. システムのリロードsystemctl daemon-reload
  5. 新しく作成されたサービスを有効にします。systemctl enable pm2.service
  6. サービス開始systemctl start pm2
  7. サービスが開始されていることを確認してsystemctl status pm2から再起動して、pm2が再度有効になっていることを確認してください。systemctl reboot
  8. 再起動後、pm2 list使用しているユーザーとして実行し、アプリケーションが実行されていることを確認します。

サービスの開始後に状態を確認することは、inactive実際には単一のスクリプトを実行して完了したサービスであるためです。

答え3

ルールを追加するだけです。サービスを開始しようとしたら、rootとしてこのコマンドを実行する必要があります(これによりタイムアウトが発生します)。

ausearch -c 'systemd' --raw | audit2allow -M my-systemd
semodule -i my-systemd.pp

今、すべてが大丈夫に見えます。再起動すると、サービスは正常に開始されます。

この回避策は新しいルールがファイルに定義されているように見えるため、一時的にのみ機能できます/tmp/my-systemd.te。内容は次のとおりです(実際に興味のある方針が含まれているようです)。

module my-systemd 1.0;

require {
        type init_t;
        type user_home_t;
        class file { open read };
}

#============= init_t ==============

#!!!! This avc is allowed in the current policy
allow init_t user_home_t:file read;
allow init_t user_home_t:file open;

関連情報