Linux 関数を使用すると、現在のaccess()ユーザーのファイル アクセス許可を確認できます。
同じ情報を提供する同様の機能がありますが、現在のユーザーをチェックする代わりに、特定のシステムユーザーの権限をチェックしますか?
のようなものint access_for(const char *pathname, uid_t uid, int mode);か何か
seteuid()同時にすべてのスレッドに影響を与えるマルチスレッド プロセス (POSIX スレッド) にこれが必要なため、使用できません。そのため、ファイルのアクセス許可を自分で確認する必要があります。
編集：プロセス自体は、少なくとも関連するユーザーの権限を持っていることがわかっている/想定されています。したがって、理論的には、ファイル システムを調べて手で権利を計算することもできますが、1 秒間に数回 (最大で数百回) チェックを実行する必要があるため、はるかに効率的な方法が必要です。可能？
それがどのように機能するかわかりません。ユーザー X として実行している場合、ユーザー Y が何かにアクセスできるかどうかを確実に確認することはできません。これは、チェックが YOUR パーミッションで行われるためです。Yつまり、偽陰性が発生する可能性があります。
TOCTOUに注意。ファイルにアクセスできることを今チェックしたとしても、今すぐアクセスできる (またはできない) という意味ではありません。よく変わりました。
したがって、正しい解決策は、ファイルにアクセスするユーザーとしてスレッド/プロセスで実行することです。そうしないと、「作業中にファイル権限が変更された」という問題が発生する危険があります。
もちろん、これは「私が誰として実行しているかに基づいて制限される可能性があるもの」へのあらゆる種類のアクセスに適用されます。
Linux では、基本的にすべてのset*id操作はスレッドローカルです。これは間違っており、準拠していません (標準では、これらの関数によって設定される ID はスレッドではなくプロセスにあると規定されています)。ユーザー空間コード (libc 内) は、繊細でエラーが発生しやすいロジックを介して問題を回避する必要があります。同期された方法ですべてのスレッド uid を変更します。syscall()ただし、syscall を ( 経由で) 直接呼び出して、1 つのスレッドだけの ID を変更できる場合があります。
また、Linuxにはsetfsuid関数で設定する「ファイルシステムuid」という概念があります。私が間違っていなければ、libc はこの 1 つのスレッド ローカルを残します。これは、どの標準でも指定されておらず (したがって、要件が課されていないため)、この関数の目的全体がスレッド ローカルで使用されるためです。している. この2番目のオプションが機能する場合は、はるかに優れていると思います.
最後に、完全に移植可能ですが遅い解決策が 1 つあります。fork次にseteuid、子で使用し、そこで呼び出しaccess、結果を親に返し_exitます。