プラットフォーム(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
が唯一の変更であったためです。
Edit1:ディレクトリでg-x,g+s
がどのように機能するかについてのセクションを削除しました。これは、ディレクトリでS
について質問していると人々が考えていたためです。私は違います。
Edit2:私は1つの答えから軽蔑を得ているので。これは、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
は実行可能ファイルでは考慮されません。
なぜ?
[〜#〜] answer [〜#〜]:私の研究 は、「システムVのため恣意的にそれは何か他のものを意味すると決めた。」
了解しました。RTFMに私に言った1つの応答からはあまり役に立ちません。数時間掘り下げた後、私は現在の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;
}
}
コメントをグーグルで検索すると、次のようになります。
https://www.kernel.org/doc/Documentation/filesystems/mandatory-locking.txt
- 必須ロック用にファイルをマークする
ファイルは強制ロックの候補としてマークされますファイルモードでグループIDビットを設定するが、グループ実行ビットを削除する。これは他の意味のない組み合わせであり、既存のユーザープログラムを壊さないようにSystemV実装者によって選択されたでした。
通常、グループIDビットは、setgidファイルが書き込まれるときにカーネルによって自動的にクリアされることに注意してください。これはセキュリティ対策です。カーネルは、必須のロック候補の特殊なケースを認識し、このビットをクリアしないように変更されました。 同様に、カーネルはsetgid特権で強制ロック候補を実行しないように変更されました。
したがって、答えは「何か他のものを意味するように選択されたため "のようです。
これを含めるように質問を編集したので:
私の質問:実行可能ファイルで大文字のS sgidが無視されるのはなぜですか?
それは無視されていません。あなたの場合のS
は、ファイルがグループによって実行可能ではないため、問題がないことを意味します。実行可能ファイルをグループのアクセス許可で実行する場合は、グループで実行可能である必要があります。 g-x
でそれを取り除いたので、S
を取得しています。グループの権限ではなく、それを実行する人の権限で実行されます。