getlogin() 이해하기

getlogin()그리고 logname(call 만 getlogin()) 현재 tty를 조회 utmp하고 해당 레코드에서 발견된 로그인 이름을 보고하여 utmp로그인 사용자 이름을 가져옵니다 . 이렇게 하는 이유는 여러 사용자 이름이 동일한 uid에 매핑될 수 있는 시스템에서 작동하도록 설계되었기 때문입니다(이러한 관행은 일반적으로 눈살을 찌푸리지만 때로는 여러 루트 계정을 만들거나 사용자 정의 셸을 시작하는 데 사용됩니다. 다른 로그인이지만 모두 동일한 기본 uid에 매핑됨). 이러한 계정과 함께 사용하면 getpwuid(getuid())passwd 데이터베이스에서 첫 번째 일치만 보고되고 getlogin()실제로 로그인에 사용된 계정이 검색됩니다.

그러나 해당 함수는 쓰기 가능한 파일의 내용에 의존하기 때문에 와 비교할 가치가 없습니다 getpwuid(getuid()). 실제로 권한이 있는 프로세스만 쓸 수 있어야 utmp하지만 일반적으로 쓸 수 있도록 구성된 "추가" 프로그램이 있습니다. (보통 setgid-를 통해 utmp) GNU screen과 같은 프로그램을 신뢰하고 싶지 않을 것입니다. 나는 역사적으로 utmp가끔 손상되기 쉬운 일부 SysV 시스템을 관리해 왔다는 것을 알고 있습니다.

@Celada가 지적했듯이 logname둘 다 getlogin()이에 의존 /var/run/utmp하므로 중간 정도의 신뢰도를 갖습니다(커널 구조와 달리 재부팅 시 반드시 재생성되는 파일이 아닌 일반 파일이므로 CD 등에서 다운로드할 수 있는 경우). 그리고 뭐할 수 없다그렇게 한다면 타협할 것인가? ). 그러나 희망은 있습니다. /proc/$$/loginuid호출하는 사용자가 소유하고 소유자에 대해 쓰기 가능한 비트가 설정되어 있기 때문에 지금까지 이것을 의도적으로 무시해 왔습니다. 따라서 보안 메커니즘보다는 대부분 편의를 위한 것이라고 생각합니다. 이 가정은 잘못된 것 같습니다. 설명문입니다커널 패치2011년 말에 제출됨:

현재 CAP_AUDIT_Control이 있는 경우 작업에서 loginuid를 설정할 수 있습니다. 실제로 우리는 로그인 시 loginuid를 설정하고 재설정이 불가능하도록 하는 작업을 원합니다. CAP를 사용하여 설정한 후에도 업데이트할 때 관리자가 sshd를 다시 시작해야 할 수 있으므로 변경 가능하게 만들어야 합니다. 이제 sshd는 LoginUID를 얻게 되며 ssh를 사용하여 로그인하는 다음 사용자는 LoginUID를 설정할 수 없습니다.

Systemd는 사용자 공간이 작동하는 방식을 변경하고 커널이 원하는 방식으로 작동하도록 허용합니다. systemd를 사용하는 사용자(관리자라도)는 서비스를 직접 다시 시작하면 안 됩니다. 시스템은 해당 서비스를 다시 시작합니다. 따라서 systemd는 loginuid==-1을 얻으므로 sshd는 -1을 얻고 sshd는 특별한 권한 없이 새 loginuid를 설정할 수 있습니다.

해당 시스템의 관리자가 sshd를 수동으로 시작한다면 그는 시스템의 신뢰 체인에 자신을 삽입하게 되므로 논리적으로 그의 로그인 사용자 이름을 사용해야 합니다!

그렇다면 사용자가 쓰기 가능한 것으로 나열되어 있습니까? 예. 사용자가 실제로 변경할 수 있나요? 루트이거나 CAP_AUDIT_Control이 있는 경우에만 가능합니다(아마도 많지 않을 것입니다). 내가 찾을 수 있는 가장 안전한 해결책은 실제로 /proc/$$/loginuid(셸 스크립트를 작성하거나 명령줄에서 작성하는 경우) 또는 프로그램 에서 추출하는 것입니다 audit_getloginuid().