"유효한 보충 GID 설정" 시스템 호출이 없는 이유는 무엇입니까?

"유효한 보충 GID 설정" 시스템 호출이 없는 이유는 무엇입니까?

프로세스의 "유효 사용자/그룹 ID"는 운영 체제에서 프로세스가 특정 작업(예: 파일 열기)을 수행할 수 있는지 여부를 결정하는 데 사용됩니다. 다음을 사용하여 현재 프로세스의 효과적인 기본 GID를 설정할 수 있습니다.setegid, 슈퍼유저(또는 가능한 경우)만 일시적으로 권한을 낮추는 데 사용할 수 있습니다.

보충 GID는 프로세스가 작업을 허용하는지 확인하는 데에도 사용되는 추가 그룹입니다. 예를 들어, 파일이 디렉토리 구조에 있고 /A/B/C/file.txt디렉토리 A, 및 디렉토리가 B각각 C소유자로 잠겨 있는 읽기 액세스 권한을 갖고 있는 경우 프로세스 groupA에는 보조 그룹 또는 유효 GID에 3개의 그룹이 모두 필요합니다.groupBgroupC

하나 있다setgroupssyscall 과 유사합니다 setgid. 즉, 프로세스 환경을 영구적으로 변경합니다. 보조 그룹(예: ) setegroups에 대한 "유효한" 시스템 호출이 필요하지 않습니까?

답변1

보조 그룹 자체를 고려할 수 있으므로 그러한 시스템 호출은 존재하지 않습니다.효과적인그룹.

실제 UID와 GID의 차이점은 프로세스가 권한을 포기할 수 있도록 허용할 뿐만 아니라 사용자가 (setuid/setgid 파일 시스템 비트를 통해) 특정 프로세스를 호출하여 권한을 늘릴 수 있도록 하기 위한 것입니다. 두 경우 모두, 권한을 높이거나 낮추는 프로세스 뒤에 있는 사용자의 실제 UID 및 GID(유효 UID 및 GID)를 추적하려고 합니다.

groups보조 그룹은 파일에서 쉽게 복구할 수 있으므로 이러한 차이가 필요하지 않습니다 .

베팅을 할 때 주의하세요.특권을 포기하다, 애플리케이션은 일반적으로 다음을 호출합니다.initgroups새 사용자의 유효 uid 및 gid와 일치하도록 그룹을 재설정합니다. 따라서 이전에 존재했을 수 있는 다른 보충 그룹에 대한 액세스 권한을 잃게 됩니다.

~에서다른 소스:

"setgroups의 유일한 사용은 일반적으로 getgrent, setgrent 및 endgrent 함수를 사용하여 전체 그룹 파일(앞서 설명한)을 읽고 사용자 이름의 그룹 멤버십을 결정하는 initgroups 함수에서 비롯됩니다. 그런 다음 setgroups를 호출하여 초기화합니다. 보충 그룹 사용자의 ID 목록은 setgroup을 호출하므로 initgroup을 호출하려면 수퍼유저여야 합니다.

관련 정보