setgid: chmod g+s,gx 실행 파일

setgid: chmod g+s,gx 실행 파일

내 플랫폼(우분투)의 실행 파일에 대한 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. 그룹이 아닌 실행하는 사람의 권한으로 실행됩니다.

관련 정보