web-dev-qa-db-ja.com

Fedora Coreのアップグレード後、バイナリ実行可能ファイルのSETUID / SETGIDが機能しなくなりました

保護されたディレクトリにアクセスする必要のあるCプログラムがあります。強力なテキストプログラムまたは管理者だけがアクセスできるという考えです。

過去のLinuxプラットフォームでは、ファイルシステムのSETUIDビットとSETGIDビットをかなりうまく使用しました。プログラムは、ファイルシステムが実行可能ファイルの所有者であると言っているUIDとGIDが何であれ問題なく実行されます。誰が実行しても。

または、以前は正常に実行されていました。

ハードウェア障害が発生したときにのみOSを更新する傾向があるため、この変更がいつ発生したかは正確にはわかりません。両方の更新を一度に取得します...したがって、多くのバージョンがスキップされるため、私は、それだけです。現在、Fedora Core 17にある開発システムは、これらのビットを尊重していません。 FC 19が現在のリリースであるため、状況は最新のリリースで悪化するだけで、良くなることはないと思います。

'ls-l'の出力は次のとおりです。

-rwsrwsr-x 1 cu cu 26403 Aug 28  2012 comp

解決策を調査したところ、chmodのmanページに次のように書かれていることがわかりました。

追加の制限により、MODEまたはRFILEのset-user-IDビットとset-group-IDビットが無視される場合があります。この動作は、基盤となるchmodシステムコールのポリシーと機能によって異なります。疑わしい場合は、基になるシステムの動作を確認してください。

OK、しかし私にはありませんIDEA提案されたポリシーと機能をチェックする方法！彼らはinfoコマンドを使用する以外に助けを提供しませんでした-しかし私はそこで何も役に立ちませんでした、デフォルトユーザーと新しいファイルを作成するためのグループ所有権。

SELINUXはオフになっています。

質問：

  1. 現代においてこの種のことを行うための「正しい」方法は何ですか？

  2. ポリシーを確認して変更するにはどうすればよいですか？

ご入力いただきありがとうございます。

より多くのデータ：

Cプログラムには、エラーを出力するために分岐する次の行があります-抜粋：

  line=malloc(large);
  if (!line) printf("virtual memory exhausted\n");
  if (line && FileExists(filename))
  {
     if (access(filename,R_OK)==0)
     {
        cfile=fopen(filename, "r");
setuidsetgidfedora
1
Richard T

あなたの場合の問題は、access()の使用です。

_man 2 access_ページには次のように書かれています。

_  The check is done using the calling process's real UID and GID,  rather
  than the effective IDs as is done when actually attempting an operation
  (e.g., open(2)) on the file.  This allows set-user-ID programs to  eas‐
  ily determine the invoking user's authority.
_

Setuidバイナリを使用して実行する場合は、実際のUIDではなく有効 UIDのみを変更します。したがって、access()呼び出しは常に失敗します。

access()を削除する必要があります。とにかくファイルを開くためにfopenを使用するので、この場合は冗長です。また、そのようなアクセスチェックを実行してから読み取りを実行するのも競争力があります。

1
Matthew Ife