!["logname" 유틸리티를 올바르게 대체합니까? [폐쇄]](https://linux55.com/image/106432/%22logname%22%20%EC%9C%A0%ED%8B%B8%EB%A6%AC%ED%8B%B0%EB%A5%BC%20%EC%98%AC%EB%B0%94%EB%A5%B4%EA%B2%8C%20%EB%8C%80%EC%B2%B4%ED%95%A9%EB%8B%88%EA%B9%8C%3F%20%5B%ED%8F%90%EC%87%84%5D.png)
논의한 바와 같이, 이 logname유틸리티는 보안상의 이유로 의도적으로 손상된 것에 의존했기 때문에 얼마 전부터 많은 사용자가 사용할 수 없게 되었습니다.여기. 토론 내용을 읽어보니 해당 기능이 복원될 가능성은 거의 없습니다.
한동안 해결 방법을 사용해 왔지만 이제 불편해지기 시작하는 것 같아서 적합한 장기 솔루션을 찾고 있는데 해결 방법이 많지 않은 것 같아 놀랐습니다. 저 밖에.
가장 일반적으로 연결된 솔루션 제시여기, 하지만 이는 다음에서 유래합니다.여기SUDO_USER환경 변수를 통해 제안된 솔루션은 이식성이 없다는 힌트도 있습니다 .
또 다른 제안된 해결책은 사용자 이름을 포함하는 파일을 생성하고 로그 이름 기능을 시뮬레이션하기 위해 bash 별칭 또는 유사한 것을 작성하는 것입니다. 그러나 적어도 환경 제어 가능성에 대한 지식을 가정하기 때문에 이를 적절한 대안이라고 부르지는 않습니다. 항상 가능하지는 않지만 적어도 경우에는 가장 잘 말합니다.
해결책은 who다음에서 비롯됩니다.여기흥미롭지만 관련된 신뢰성이나 이식성 제한이 있는지에 대한 정보를 찾을 수 없습니다.
이러한 방법들 외에도 이 분야의 공기는 매우 빠르게 희박해지고 있기 때문에 이 주제에 대한 새로운 의견과 지금까지의 내 생각을 얻고자 여기에 질문하기로 결정했습니다.
답변1
TL,DR: 동작이 항상 일치하지 않더라도 그렇게 하고 싶을 수도 있습니다. 그러나 모든 배포판에서 기본적으로 작동하는 것은 아닙니다. 내 대답은 Linux를 가정하고 다른 Unix 변형에서는 작동하지 않습니다./proc/PID/loginuidlogname
이에 대한 명확한 기대가 없기 때문에 완전히 만족스러운 답변을 찾을 수는 없을 것 같습니다 logname. 한편으로는 현재 lognameutmp 레코드를 기반으로 하는 레코드를 사용하고 있습니다. 이 레코드는 사용자를 터미널과 연결하고 터미널 에뮬레이터의 요구 사항에 따라 업데이트됩니다(많은 터미널 에뮬레이터에서는 이 작업을 수행하지 않음). 반면에 "사용자 이름을 변경할 가능성은 슈퍼유저로 제한되어야 한다"고 예상합니다. utmp 레코드의 경우에는 그렇지 않습니다! 설명대로당신이 인용한 댓글 스레드에서, utmp 레코드는 대부분의 경우 작동하지만 위조될 수 있습니다.
"콘솔에 로그인하는 데 사용되는 사용자 이름"을 정의하는 것은 문제가 있습니다. 명목상의 상황은 분명하지만 많은 합병증이 있습니다. 사용자가 다른 사용자의 스크린 세션에 전화를 걸어 연결하면 su어떻게 되나요 ? 사용자가 다른 사용자의 X11 또는 VNC 세션에 연결하면 어떻게 됩니까? 프로세스를 터미널까지 추적하는 방법 - 제어 터미널이 없는 프로세스는 어떻게 해야 합니까?
실제로 리눅스하다"로그인 UID"라는 개념이 있습니다. 모든 프로세스에 표시됩니다. 이 정보는 커널에 의해 추적되지만 로그인이 발생할 때 커널에 알리는 것은 사용자 모드입니다. 이는 일반적으로 다음과 같이 수행됩니다./proc/PID/loginuidpam_loginuid. 뒤에서는 글쓰기로 이루어집니다 /proc/self/loginuid. Linux의 로그인 UID는 프로세스 조상을 따르는데, 이는 항상 올바른 정의는 아니지만 단순하다는 장점이 있습니다.
프로세스의 로그인 UID가 4294967295인 경우 프로세스가 이를 변경할 수 있습니다. 초기화는 로그인 UID 4294967295(32비트 값 -1과 동일)로 시작됩니다.로그인 세션의 일부가 아닌 프로세스를 나타냅니다.. 로그인 프로세스가 로그인 UID를 올바르게 설정하는 한(루트에서 로그인 사용자에게 실제 UID를 설정하기 직전) 괜찮습니다. 그러나 로그인 UID를 설정하지 않고 로그인할 수 있는 방법이 있다면 사용자는 자신이 선택한 로그인 UID를 선언할 수 있습니다. 따라서 이 정보는 시스템에서 프로세스를 실행하는 모든 방법이 로그인 UID 설정 단계를 거치는 경우에만 신뢰할 수 있습니다. 한 단계를 잊어버리면 정보가 쓸모 없게 됩니다.
실험적으로 Debian jessie 머신에서 로그인 UID -1을 사용하여 오랫동안 실행되는 모든 프로세스는 시스템 서비스입니다. 그러나 incron과 같이 로그인 UID -1로 프로세스를 실행하는 방법이 있습니다. 나는 다른 많은 방법을 모릅니다. incron은 처음 시도한 것이었고 효과가 있었습니다. Ubuntu 16.04 시스템에서는 pam_loginuidlightdm 항목이 주석 처리되어 있지만 이유는 조사하지 않았습니다. Ubuntu의 lightdm 및 incron은 보안 버그로 간주되어야 할 수도 있지만 사실 오늘날 주요 배포판에서는 기본적으로 로그인 UID를 사용할 수 없습니다.
당신은 또한 볼 수 있습니다Loginuid, 변경이 허용되어야 합니까(변경 가능 또는 불변)?, 이는 루트가 로그인 UID를 변경하는 것을 방지하는 커널 옵션에 관한 것입니다. 그러나 이는 로그인 UID가 적절한 값으로 설정된 경우에만 작동한다는 점에 유의하세요. 사용자가 로그인 UID를 여전히 -1로 설정한 상태에서 프로세스를 실행하는 경우 원하는 값으로 설정할 수 있습니다. 실제로 init를 다른 값(예: -2)으로 전환하고 pam_loginuid해당 값을 덮어쓰는 것이 더 안전합니다. 그러면 -1은 절대 발생하지 않으며 -2는 "알 수 없음"을 의미합니다.