スクリプトでsetuidを有効にするのにセキュリティ上の問題があることがわかっているので、デフォルトでは無効になっていますが、実行可能ファイルでは機能します。この資料に記載されている指示に従って、uidを出力としてマークする実行可能ファイルを作成しました。シェルスクリプトでsetuid設定を許可する
ただし、実行の前後に同じuid（1000）を返しますsudo chmod +s ./setuid-test。これは、setuidが私の実行可能ファイルに影響を与えないことを意味すると思います。理由と回避策は何ですか？
ソースコード：
#include <stdio.h>
#include <unistd.h>
int main(int argc, char** argv) {
printf("%d", geteuid());
return 0;
}
ビルドと実行
$ gcc -o setuid-test setuid-test.c
$ ./setuid-test
1000
$ sudo chown nobody ./setuid-test; sudo chmod +s ./setuid-test
$ ./setuid-test
1000
実行すると、ls -la次のような結果が得られます。
me@me:~$ ls -la setuid-test
-rwsrwsr-x 1 nobody me 8572 Aug 19 16:39 setuid-test
ベストアンサー1
Unix / Linux用に設計されたほとんどのファイルシステムはnosuid属性を使用してマウントできます。これにより、これらのファイルシステム内のsetuidまたはsetgidバイナリがプロセスの有効なuidまたはgidを変更するのを防ぎます。通常、「信頼できない」ファイルシステム（つまり、管理者が制御しないファイルシステム）をマウントするときに使用されます。
あなたの場合、使用しているファイルシステムの種類は次のようにecryptfsです。askubuntu：暗号化されたホームディレクトリでroot setuidを使用してバイナリを実行中にエラーが発生しました。数年前のバージョンからnosuid（およびnodev）は自動的に適用されます。
以下は、変更理由の説明です。https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-3409:
Vincent Danen 2012-07-20 11:25:56 EDT
setuid-rootとしても知られるプライベートecryptfsマウントヘルパー（/sbin/mount.ecryptfs_private）を使用すると、権限のないローカルユーザーがユーザー制御ecryptfsをマウントできることが報告されています。システムでローカルに共有します。 ecryptfsヘルパーは「nosuid」フラグと「nodev」フラグを使用してファイルシステムをマウントしないため、ユーザーはsetuid-rootバイナリおよび/またはデバイスファイルを含むファイルシステムをマウントして権限を昇格できます。ユーザーがシステムに物理的にアクセスできる場合は、USBデバイスを介してこれを行うことができます。
...
必須 MS_NOSUID および MS_NODEV インストール フラグがバージョン 99 に追加されました。