☰

ID 결과는 요청하는 사람에 따라 다릅니다.

tag-icon • tag-icon root usermod
ID 결과는 요청하는 사람에 따라 다릅니다.

내 userX는 라이브 그룹을 통해 라이브 권한을 갖습니다. 이 사용자에게 관리자 권한을 부여하고 싶어서 루트로 전환합니다.

~>su root

그러다가 도망갔어

#>usermod -a -G root userX

잠시 후 프롬프트로 돌아가서 효과를 테스트했습니다.

#>id userX
#>uid=1000(userX)  gid=0(root) groups=0(root),1001(realtime)

그래서 성공한 것 같아요. 더미 사용자를 추가하여 종료하고 새 관리자를 테스트했습니다.

#>exit
~>useradd BSD
bash: /usr/sbin/useradd: Permission denied

문제가 있습니다. 내 그룹 멤버십을 확인하려고 했는데 다른 답변이 나왔습니다.

~>id
~>uid=1000(userX)  gid=1001(realtime) groups=1001(realtime) contextunconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

따라서 내 사용자는 자신이 루트의 일부가 아니라고 말하지만 루트는 사용자가 루트의 일부라고 말하는 이유를 알아야 합니다. 내가 무엇을 놓치고 있나요?

답변1

무슨 일이에요?

사용자가 속한 그룹 목록은 로그인 시에만 설정됩니다(거의 사용되지 않는 sg명령을 사용하여 수정할 수 있지만 그룹에 대해 그룹 비밀번호가 설정된 경우에만 가능). 사용자가 로그아웃했다가 다시 로그인하면 그룹에 자신이 포함되어 있는 것을 볼 수 있습니다. 그러나 GID 0(대부분의 Linux 시스템에서는 "root", 대부분의 비 Linux 시스템에서는 "wheel" 또는 "adm") 그룹에 속한다고 해서 실제로 보안 관점에서 볼 때 관리 권한이 있는 것은 아닙니다.

이것이 행정권과 다른 이유는 무엇입니까?

루트 사용자(UID 0)는 특별합니다. 루트 그룹(GID 0, wheel찾을 수 없는 역사적인 이유로 많은 비 Linux 시스템에서 호출됨)은 그렇지 않습니다. 귀하의 사용자는 루트 그룹이 소유한 파일에 액세스할 수 있지만 다른 권한은 없을 수 있습니다. 이것은 다소 복잡한 구별이지만 매우 중요한 구별입니다.

이것이 왜 나쁜 생각입니까?

항상 루트로 실행하는 것이 나쁜 생각인 것과 거의 같은 이유로 이것은 나쁜 생각입니다. 시스템을 사용할 수 없게 만드는 것은 항상 한 번의 실수입니다(예를 들어 대부분의 Linux 시스템에서 루트 그룹의 일부가 되면 내용을 삭제할 수 있기 때문에 쉽게 시스템을 부팅할 수 없게 만들 수 있습니다 /boot).

이 사용자에게 관리 권한을 부여하는 정확하고 안전한 방법은 무엇입니까?

가능하다면 sudo시스템에 존재하는 doas기타 권한 상승 도구를 설정하여 액세스를 허용하세요. su그러한 도구가 없다면 su하나 설치하십시오(저는 sudo가장 널리 사용되는 도구이므로 문서가 많기 때문에 배우기 가장 쉬운 도구 중 하나입니다). 이것이 옵션이 아닌 경우 su관리 작업을 수행해야 할 때 직접 권한 상승이 올바른 선택입니다. 단, su이를 통해 호출된 명령의 환경은 제대로 재설정되지 않으므로 주의해야 합니다.

관련 정보