/bin, /boot 및 /dev에 대한 권한이 손상되었습니다. 혼란스러운 부분을 정리하는 방법은 무엇입니까?

/bin, /boot 및 /dev에 대한 권한이 손상되었습니다. 혼란스러운 부분을 정리하는 방법은 무엇입니까?

방금 끔찍한 실수를 저질렀고 스스로 고치려고 노력하고 있지만 도움이 필요합니다.

구문 오류로 인해 모든 파일 및 폴더 권한이 변경되었습니다. 운 좋게도 이 문제가 발생하는 동안 이를 보고 성공적으로 방지했습니다. "만" /bin, /boot/dev영향을 받습니다. 다음은 발생한 사건의 일부입니다(전체 로그:http://pastebin.com/4BkbXEqD):

Apr 11 21:34:08 *** sftp-server[20582]: set "/.newrelic" mode 40754
Apr 11 21:34:08 *** sftp-server[20582]: set "/bin" mode 40554
Apr 11 21:34:09 *** sftp-server[20582]: set "/boot" mode 40554
Apr 11 21:34:09 *** sftp-server[20582]: set "/cgroup" mode 40754
Apr 11 21:34:09 *** sftp-server[20582]: set "/dev" mode 40754
Apr 11 21:34:09 *** sftp-server[20582]: opendir "/.newrelic"
Apr 11 21:34:09 *** sftp-server[20582]: closedir "/.newrelic"
Apr 11 21:34:09 *** sftp-server[20582]: opendir "/.newrelic"
Apr 11 21:34:10 *** sftp-server[20582]: closedir "/.newrelic"
Apr 11 21:34:10 *** sftp-server[20582]: opendir "/"
Apr 11 21:34:10 *** sftp-server[20582]: closedir "/"
Apr 11 21:34:10 *** sftp-server[20582]: opendir "/bin"
Apr 11 21:34:10 *** sftp-server[20582]: closedir "/bin"
Apr 11 21:34:10 *** sftp-server[20582]: set "/bin/mknod" mode 100754
Apr 11 21:34:10 *** sftp-server[20582]: set "/bin/cat" mode 100754
Apr 11 21:34:10 *** sftp-server[20582]: set "/bin/ping6" mode 100754

예를 들어 MySQL은 더 이상 실행되지 않고 있어 피해가 더욱 클 것 같습니다.

이러한 폴더와 파일에 대한 읽기 및 실행 권한을 복원하려고 시도했지만 실제로 이전 상태가 어떤 것인지 전혀 모릅니다.

시스템을 작동 상태로 복원하는 방법은 무엇입니까?

답변1

루트 셸을 시작했다면 루트 셸에서 권한을 복원할 수 있어야 합니다. 콘솔에 루트로 로그인하면 루트 쉘을 얻을 수 있습니다. 이 시점에서 구성에 따라 su일반 계정을 사용하여 루트 액세스 권한을 얻을 수도 있고 얻지 못할 수도 sudo있으며, 루트가 아닌 계정을 사용하여 로그인하지 못할 수도 있습니다.

게시한 기록이 완전하다면 운이 좋을 것이며 파일( /etc및 복구하기 가장 어려운 권한이 있는 파일 /var)은 영향을 받지 않을 것입니다.

Apr 11 21:34:08 *** sftp-server[20582]: set "/.newrelic" mode 40754
Apr 11 21:34:08 *** sftp-server[20582]: set "/bin" mode 40554
Apr 11 21:34:09 *** sftp-server[20582]: set "/boot" mode 40554
Apr 11 21:34:09 *** sftp-server[20582]: set "/cgroup" mode 40754
Apr 11 21:34:09 *** sftp-server[20582]: set "/dev" mode 40754

40754(8진수 표기법)는 소유자가 쓸 수 있고 소유자와 그룹이 실행 가능하며 모든 사람이 읽을 수 있는 디렉터리를 나타냅니다. 가장 오른쪽 세 자리만 권한을 나타내며 앞의 숫자는 파일 형식을 인코딩하며 변경할 수 없습니다. 디렉터리에 대한 "실행" 권한은 실제로 해당 디렉터리의 파일에 액세스할 수 있는 권한을 의미하므로 대부분의 사용자는 더 이상 해당 디렉터리의 파일에 액세스할 수 없습니다. 대부분의 최상위 디렉토리에는 권한 755가 있어야 합니다. 이는 모든 사람이 읽고 실행할 수 있으며 소유자만 쓸 수 있음을 의미합니다(예외는 /lost+found일반적으로 700 /tmp이며 1777이어야 하며 소유자와 같은 특수 파일 시스템에는 /proc/sys수 없습니다). 그것이 무엇인지 모릅니다 /.newrelic. 표준 최상위 디렉토리가 아닙니다.

chmod 755 /bin /boot /cgroup /dev
Apr 11 21:34:10 *** sftp-server[20582]: set "/bin/mknod" mode 100754

/bin및 에 있는 대부분의 파일은 /sbin모든 사람이 읽고 실행할 수 있어야 하며 소유자만 쓸 수 있어야 합니다. 그들 중 몇몇은 필요합니다사용자 ID 설정.

chmod a+x /bin/* /sbin/*
chmod 4755 /bin/su /bin/sudo /bin/mount /bin/umount /bin/ping /bin/ping6
chmod 4754 /bin/fusermount

내 생각 에는 /boot모든 파일과 디렉터리는 누구나 읽을 수 있어야 하고 디렉터리는 실행 가능해야 하지만 파일은 그렇지 않아야 합니다.

find /boot -type d -exec chmod 755 {} + -type f -exec chmod 644 {} +

이로 인해 /dev파일 간에 권한이 크게 달라집니다. 다행히 /dev인메모리 파일 시스템이라 재부팅 후에는 문제가 없을 것입니다. 재부팅하지 않고 권한을 복원 할 수 있고 원한다면 /dev다음 명령이 효과가 있을 것이라고 생각합니다.

udevadm trigger --sysname-match='*'

답변2

실제로 시스템은 로그에 나타난 것보다 더 심각한 영향을 받은 것 같습니다!
어쩌면 개발 폴더 때문일 수도 있고, 심볼릭 링크 때문일 수도 있습니다. 하지만 포럼 등을 크롤링하고 폴더별로 시도한 후 마침내 다음 명령으로 서버를 저장했습니다.

for package in $(rpm -qa); do rpm --setperms $package; done

@Gilles와 그의 훌륭한 답변에 특별히 감사드립니다
! @dhag가 내 질문을 편집하여 정중한 공식을 삭제했습니다.

관련 정보