私のプラットフォーム（Ubuntu）の実行可能ファイルのsetgidを理解していません。g-x,g+sプロセスには、プログラム所有者に対する有効なグループ権限が付与されていません。
$ gcc perms.c -o perms; ls -l ; ./perms
-rwxr-xr-x 1 ubuntu ubuntu 9302 Feb 24 01:00 perms*
-rw-r--r-- 1 ubuntu ubuntu 1437 Feb 21 08:41 perms.c
ruid: ubuntu:1000 group:1000
euid: ubuntu:1000 group:1000
$ sudo useradd alice; groups alice $USER
alice : alice
ubuntu : ubuntu sudo rvm
$ chmod g+s ./perms; ls -l ./perms ; sudo -u alice ./perms
rwxr-sr-x 1 ubuntu ubuntu 9302 Feb 24 01:00 perms*
ruid: alice:1001 group:1002
euid: alice:1001 group:**1000**
これらすべてが予想されます。質問は次のとおりです。
$ chmod g-x ./perms; ls -l ./perms ; sudo -u alice ./perms
-rwxr-Sr-x 1 ubuntu ubuntu 9302 Feb 24 01:00 perms*
ruid: alice:1001 group:1002
euid: alice:1001 group:**1002**
私が理解しているのは、これがg+sプロセスにプログラム所有者の有効なグループIDを提供することです。しかし、これは本当ではありません。明らかにこれがg-x唯一の変化だからです。
g-x,g+s編集1：人々は私がディレクトリについて尋ねたと思ったので、ディレクトリのしくみに関するセクションを削除しましたS。私はそうではありません。
Edit2：なぜなら私は答えで屈辱感を感じたからです。これは以下とも異なりますu-x,u+s。
$ rm -rf perms temp/; gcc perms.c -o perms
$ chmod ug-x,ug+s ./perms; ls -l ./perms; sudo -u alice ./perms
-rwSr-Sr-x 1 ubuntu ubuntu 9302 Feb 24 21:22 ./perms*
ruid: alice:1001 group:1002
euid: ubuntu:1000 group:1002
ここでは尊重が尊重u-x,u+sされますが、g-x,g+sそうではありません。
私の質問：capital S sgid実行ファイルが無視されるのはなぜですか？
g-x,g+sディレクトリから敬意を得てください。
u-x,u+s実行ファイルを尊重します。
しかし、g-x,g+s実行ファイルでは尊重されません。
なぜ？
回答: 私の研究「システムVがランダムに違う意味を決めたから」という厄介な路地に到達したようです。
ベストアンサー1
まあ、RTFMの答えは私にとってあまり役に立ちません。数時間調査したところ、現在のLinuxカーネルで次の行が見つかりました。
https://github.com/torvalds/linux/blob/e816c201aed5232171f8eb80b5d46ae6516683b9/fs/exec.c
/* Be careful if suid/sgid is set */
inode_lock(inode);
/* reload atomically mode/uid/gid now that lock held */
mode = inode->i_mode;
uid = inode->i_uid;
gid = inode->i_gid;
inode_unlock(inode);
/* We ignore suid/sgid if there are no mappings for them in the ns */
if (!kuid_has_mapping(bprm->cred->user_ns, uid) ||
!kgid_has_mapping(bprm->cred->user_ns, gid))
return;
if (mode & S_ISUID) {
bprm->per_clear |= PER_CLEAR_ON_SETID;
bprm->cred->euid = uid;
}
if ((mode & (S_ISGID | S_IXGRP)) == (S_ISGID | S_IXGRP)) {
bprm->per_clear |= PER_CLEAR_ON_SETID;
bprm->cred->egid = gid;
}
これは意図的なことが明らかです。
これは2005年5月にgithubにオリジナルがアップロードされた時点にさかのぼります。
https://github.com/torvalds/linux/blob/3677209239ed71d2654e73eecfab1dbec2af11a9/fs/exec.c
bprm->e_uid = current->euid;
bprm->e_gid = current->egid;
if(!(bprm->file->f_vfsmnt->mnt_flags & MNT_NOSUID)) {
/* Set-uid? */
if (mode & S_ISUID) {
current->personality &= ~PER_CLEAR_ON_SETID;
bprm->e_uid = inode->i_uid;
}
/* Set-gid? */
/*
* If setgid is set but no group execute bit then this
* is a candidate for mandatory locking, not a setgid
* executable.
*/
if ((mode & (S_ISGID | S_IXGRP)) == (S_ISGID | S_IXGRP)) {
current->personality &= ~PER_CLEAR_ON_SETID;
bprm->e_gid = inode->i_gid;
}
}
Google でレビューを検索すると、次のような結果が表示されます。
https://www.kernel.org/doc/Documentation/filesystems/mandatory-locking.txt
- ファイルを強制ロックとしてマーク ファイルは
強制ロック候補として表示されます。ファイルモードではグループIDビットを設定しますが、グループ実行ビットは削除します。。これは言わない組み合わせです。System V 実装者によって選択既存のユーザープログラムが破損しないようにします。
カーネルは通常 setgid ファイルに書き込むと group-id ビットを自動的にクリアします。これは安全対策です。強制ロック候補である特別な場合を認識し、このビットをクリアしないようにカーネルが修正されました。同様に、カーネルはsetgid権限で強制ロック候補を実行しないように修正されました。
だから答えは「そうだ。別の意味で選ばれたからです。」