다음 오류가 발생합니다 sudo
.
$ sudo ls
sudo: /etc/sudoers is owned by uid 1000, should be 0
sudo: no valid sudoers sources found, quitting
sudo: unable to initialize policy plugin
물론 chown
, root
사용되지 않는 경우에는 sudo
당사 계정에 비밀번호가 없습니다 root
.
솔직히 시스템이 어떻게 이렇게 엉망이 되었는지는 모르겠지만, 이제는 내가 고쳐야 할 차례입니다.
일반적으로 복구 모드로 부팅하지만 시스템은 원격이며 일반 부팅 시 VPN을 통해서만 액세스할 수 있습니다. 같은 이유로 Live CD나 USB 스틱에서 부팅하는 것은 비현실적입니다.
시스템은 Ubuntu 16.04(EOL 종료, 묻지 않음)이지만 질문과 답변은 아마도 더 일반적일 것입니다.
답변1
설명된 절차여기(그 자체가 불완전한 사본일 수도 있습니다.우분투 답변에 물어보세요) 기적을 일으켰습니다. 여기에 복사하고 설명을 더 추가하겠습니다.
프로그램
대상 서버에 대한 두 개의 SSH 세션을 엽니다.
첫 번째 세션에서 다음을 실행하여 bash의 PID를 가져옵니다.
echo $$
두 번째 세션에서는 다음 명령을 사용하여 인증 브로커를 시작합니다.
pkttyagent --process 29824
1단계에서 얻은 pid를 사용합니다.
첫 번째 세션으로 돌아가서 다음을 실행합니다.
pkexec chown root:root /etc/sudoers /etc/sudoers.d -R
두 번째 세션 비밀번호 프롬프트에 비밀번호를 입력하세요.
설명하다
sudo
와 유사하게 pkexec
승인된 사용자가 다른 사용자(일반적으로 )로서 프로그램을 실행할 수 있도록 허용합니다 root
. 특히 인증을 위해 polkit을 사용합니다 org.freedesktop.policykit.exec
.
이 작업은 다음에 정의되어 있습니다 /usr/share/polkit-1/actions/org.freedesktop.policykit.policy
.
<action id="org.freedesktop.policykit.exec">
<description>Run programs as another user</description>
<message>Authentication is required to run a program as another user</message>
<defaults>
<allow_any>auth_admin</allow_any>
<allow_inactive>auth_admin</allow_inactive>
<allow_active>auth_admin</allow_active>
</defaults>
</action>
auth_admin
관리 사용자가 이 작업을 수행할 수 있음을 나타냅니다. 누가 관리 사용자가 될 수 있나요?
이 특정 시스템(Ubuntu 16.04)에서 구성은 다음과 같습니다 /etc/polkit-1/localauthority.conf.d/51-ubuntu-admin.conf
.
[Configuration]
AdminIdentities=unix-group:sudo;unix-group:admin
따라서 그룹의 모든 사용자가 sudo
이를 admin
사용할 수 있습니다 pkexec
.
최신 시스템(Arch Linux)에서는 다음 위치에 있습니다 /usr/share/polkit-1/rules.d/50-default.rules
.
polkit.addAdminRule(function(action, subject) {
return ["unix-group:wheel"];
});
따라서 여기서는 wheel
그룹의 모든 사람이 관리 사용자입니다.
매뉴얼 페이지 에는 pkexec
현재 세션에 대한 인증 프록시가 없으면 pkexec
자체 텍스트 인증 프록시가 사용된다고 명시되어 있습니다 pkttyagent
. 실제로 프로세스를 먼저 pkexec
시작하지 않고 실행하면 pkttyagent
시스템에 메시지가 표시됩니다. 동일한 셸에서 비밀번호를 입력했지만 비밀번호를 입력한 후 실패합니다.
polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
그것은 것 같다폴킷의 오래된 버그이것은 아무런 견인력을 얻지 못하는 것 같습니다. 더논의하다.
두 개의 쉘을 사용하는 비결은그냥 해결 방법이 질문에 대해서.
답변2
라이브 환경으로 부팅하고 거기에서 수정하세요.
이를 위해서는 분명히 "물리적으로 동등한" 물리적 액세스가 필요하지만(VM 또는 VPS를 다루는 경우) 어떤 초기화 시스템을 가지고 있는지 또는 루트 비밀번호가 있는지 여부에 관계없이 거의 항상 작동합니다.
일반적인 접근 방식은 비교적 간단합니다.
- 사용 중인 운영 체제와 호환되는 Live CD(또는 기타 부팅 미디어)를 준비합니다(대부분의 경우 이는 루트 파일 시스템을 마운트하는 데 필요한 저장소 드라이버와 파일 시스템의 특정 조합을 지원하기 위한 것입니다).
- 부팅 미디어를 사용하여 영향을 받는 시스템을 부팅합니다.
- 영향을 받는 시스템의 루트 파일 시스템을 어딘가에 마운트합니다.
- 파일을 편집하고 저장합니다.
- 재시작.
이 수정 사항은 영향을 받는 시스템의 액세스 제어를 완전히 우회하여 원하는 거의 모든 작업을 수행할 수 있도록 하기 때문에 효과적입니다. 시스템에 대한 이러한 수준의 무제한 액세스는 물리적 보안이 중요한 이유 중 하나입니다.
이 접근 방식을 사용하는 경우 "정상" 시스템으로 다시 재부팅할 때 제대로 작동하도록 하려면 몇 가지 특별한 작업을 수행해야 할 수도 있습니다. 이는 기본 Ubuntu 설치에서는 필요하지 않지만 SELinux(및 IMA 및 EVM 가능성은 거의 없음)를 사용하는 경우 추가 부팅 옵션을 추가한 다음 부팅된 시스템에서 명령을 실행하여 보안 레이블을 수정해야 할 수 있습니다.
그 사람들을 위해하다루트 비밀번호를 사용하면 단일 사용자 모드를 사용하면 됩니다.
Systemd에서는 이를 "구조 모드"라고 부르지만 다른 사람들은 이를 단일 사용자 모드라고 부릅니다. 이는 본질적으로 중요한 서비스를 실행하는 것 외에는 거의 아무것도 하지 않고 루트 셸로 부팅됩니다. 그것은 전통적으로 고정에 사용됩니다정확히이런 종류의 문제입니다.
이것의 한 가지 단점은 적절하게 보안된 최신 시스템에서 단일 사용자 모드는 비밀번호로 보호되며 루트로 로그인할 수 있는 기능이 필요하다는 것입니다(이유는 시스템 콘솔에 대한 액세스가 시스템 하드웨어에 대한 물리적 액세스를 의미하지 않기 때문입니다. 인증을 사용해야 합니다.)
답변3
구성을 시도할 때마다 sudo
다른 루트 터미널을 열어 두는 것이 좋습니다. 문제가 발생하는 경우를 대비해 이미 문제를 해결할 수 있는 권한이 있습니다.
터미널을 열어두는 것이 불가능한 경우(예: 재부팅과 관련된 실험) 사용자의 실제 비밀번호를 설정하세요 root
. 그런 다음 손상된 경우 sudo
간단히 로그인하여 root
(새 콘솔을 열거나 실행 su
) 시스템을 복구할 수 있습니다.