web-dev-qa-db-ja.com

setgid：実行可能ファイルのchmod g + s、g-x

プラットフォーム（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のため恣意的にそれは何か他のものを意味すると決めた。」

permissionsexecutablegroupsetgid
4
user211221

了解しました。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

  1. 必須ロック用にファイルをマークする
    ファイルは強制ロックの候補としてマークされますファイルモードでグループIDビットを設定するが、グループ実行ビットを削除する。これは他の意味のない組み合わせであり、既存のユーザープログラムを壊さないようにSystemV実装者によって選択されたでした。
    通常、グループIDビットは、setgidファイルが書き込まれるときにカーネルによって自動的にクリアされることに注意してください。これはセキュリティ対策です。カーネルは、必須のロック候補の特殊なケースを認識し、このビットをクリアしないように変更されました。 同様に、カーネルはsetgid特権で強制ロック候補を実行しないように変更されました。

したがって、答えは「何か他のものを意味するように選択されたため "のようです。

3
user211221

これを含めるように質問を編集したので：

私の質問：実行可能ファイルで大文字のS sgidが無視されるのはなぜですか？

それは無視されていません。あなたの場合のSは、ファイルがグループによって実行可能ではないため、問題がないことを意味します。実行可能ファイルをグループのアクセス許可で実行する場合は、グループで実行可能である必要があります。 g-xでそれを取り除いたので、Sを取得しています。グループの権限ではなく、それを実行する人の権限で実行されます。

0
Nasir Riley