setgid: chmod g+s,gx 実行可能ファイル

setgid: chmod g+s,gx 実行可能ファイル

私のプラットフォーム(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

  1. ファイルを強制ロックとしてマーク ファイルは
    強制ロック候補として表示されます。ファイルモードではグループIDビットを設定しますが、グループ実行ビットは削除します。。これは言わない組み合わせです。System V 実装者によって選択既存のユーザープログラムが破損しないようにします。
    カーネルは通常 setgid ファイルに書き込むと group-id ビットを自動的にクリアします。これは安全対策です。強制ロック候補である特別な場合を認識し、このビットをクリアしないようにカーネルが修正されました。同様に、カーネルはsetgid権限で強制ロック候補を実行しないように修正されました。

だから答えは「そうだ。別の意味で選ばれたからです。

答え2

次のように質問を編集するとき:

私の質問:実行可能ファイルが大文字のS sgidを無視するのはなぜですか?

それは目立たなかった。Sあなたの場合、これはグループでファイルを実行できないことを意味するので、問題はありません。グループの権限で実行可能ファイルを実行するには、グループで実行できる必要があります。あなたはそれを奪い、g-xそれがあなたがそれを得る理由ですS。グループではなく、実行している人の権限で実行されます。

関連情報