Linux 사용자에 대한 ID와 그룹 확인

리눅스에서의 접근 거부는 항상 잊혀진 chmod 때문만은 아닙니다. 실패하는 명령은 다른 UID로 실행되고 있을 수도 있거나, 해당 계정이 기대하는 그룹에 속하지 않을 수도 있습니다. 소유자를 변경하기 전, 실제로 사용되는 계정을 식별하는 것부터 시작하세요.

id 명령은 현재 프로세스의 UID, 기본 그룹 및 부 그룹을 표시합니다. 이는 스크립트, 서비스 또는 SSH 세션이 여러분과 동일한 파일을 보지 못할 때의 출발점입니다.

id로 UID, GID 및 그룹 읽기

문제가 되는 세션에서 인수 없이 id를 실행하세요:

id

출력 예시로 uid=1000(alex) gid=1000(alex) groups=1000(alex),27(sudo),999(docker)는 프로세스의 정체성을 설명합니다. uid는 사용자 식별자입니다. gid는 기본 그룹입니다. groups는 종종 Docker, 로그 또는 공유에 대한 접근을 여는 부 그룹을 추가합니다.

하나의 값만 얻으려면 다음 옵션을 사용하세요:

• id -u는 효과적인 UID를 표시합니다.
• id -g는 효과적인 GID를 표시합니다.
• id -Gn은 그룹의 이름을 나열합니다.
• id -un은 효과적인 계정의 이름을 표시합니다.

실제 식별자와 효과적인 식별자의 차이는 주로 sudo, SUID 바이너리 또는 사용자 전환을 수행하는 특정 도구에서 나타납니다. 이름만 빠르게 확인하려면 우리의 whoami 및 효과적인 사용자에 대한 기사도 확인하세요.

세션을 열지 않고 계정 검사하기

계정 이름을 추가하여 해당 로컬 기록을 조회하세요. 이 명령은 사용자 데이터베이스를 읽으며 해당 계정으로 로그인하지 않습니다:

id www-data
id -Gn www-data

Debian 및 Ubuntu에서 www-data는 종종 웹 서비스 계정입니다. 다른 배포판에서는 서비스가 apache, nginx 또는 응용 프로그램 계정을 사용할 수 있습니다. 이 예제를 그대로 따르지 말고 서비스의 유닛 파일이나 구성을 확인하세요.

사용자를 그룹에 추가한 후에는 이미 열린 세션이 이전 그룹 목록을 유지할 수 있습니다. 수정이 실패했다고 결론 내리기 전에 로그아웃하고 로그인하세요. id 사용자 명령은 데이터베이스를 다시 읽지만, 단독으로 id는 항상 현재 프로세스를 설명합니다.

계정 정체성과 파일 권한 비교하기

그룹을 아는 것만으로는 충분하지 않습니다. 해당 경로의 소유자, 그룹 및 권한을 읽어야 합니다:

id
stat -c '%U %G %A %n' /chemin/vers/le/fichier
namei -l /chemin/vers/le/fichier

stat는 파일의 소유자가 누구인지 알려줍니다. namei -l은 경로의 각 디렉토리 권한도 보여줍니다. 읽을 수 있는 파일은 부모 디렉토리를 통과할 수 없는 계정에게는 아무 의미가 없습니다. 이 경우 해당 디렉토리에서 x 권한이 필요합니다.

chmod 777로 거부를 수정하지 마세요. 먼저 파일의 그룹을 id -Gn과 비교한 다음, 필요한 경우 소유자, 그룹 또는 권한을 조정하세요. 그룹 및 사용에 대한 자세한 내용은 리눅스에서의 그룹 관리를 참조하세요. 권한을 수정해야 할 경우, chmod 재귀에 대한 우리의 가이드는 너무 넓은 명령이 얼마나 더 많은 파일에 영향을 미칠 수 있는지 설명합니다.

수정하기 전에 사용자 계정으로 테스트하기

관리 권한이 있을 때에는 문제를 겪고 있는 계정으로만 확인 작업을 수행하세요:

sudo -u www-data id
sudo -u www-data test -r /chemin/vers/le/fichier && echo 읽기 가능
sudo -u www-data test -x /chemin/vers/le/dossier && echo 탐색 가능

첫 번째 호출은 실제 신원을 확인합니다. 다음 두 호출은 파일 읽기 또는 디렉토리 탐색이라는 명확한 질문에 대답합니다. 실행 전에 www-data 및 경로를 바꾸세요. 생산 애플리케이션을 시작하여 권한만 테스트하기 위해 sudo -u를 사용하지 마세요.

UID, 그룹 및 Unix 권한이 올바른 것 같음에도 접근이 거부되면 getfacl로 ACL도 확인하고, 네트워크 마운트와 SELinux 또는 AppArmor를 확인하세요. 이러한 메커니즘은 일반 권한 위에 규칙을 추가할 수 있습니다.

id, stat 및 올바른 계정에서의 테스트를 통해 맹목적으로 권한을 수정하기 전에 어디서 찾아야 할지 알고 있습니다.