26

Tôi chỉ chạy cái này vài giây trước. Tôi quản lý để làm Ctrl- Cngay khi tôi nhận ra những gì tôi bắt đầu làm.

Cho đến nay thư mục duy nhất nó bắt đầu đi qua là /bin.

Tôi sợ phải làm bất cứ điều gì khác. Cho đến nay tôi nhận ra tôi không thể sử dụng sunhư người dùng bình thường của mình nữa.

May mắn là tôi vẫn còn một thiết bị đầu cuối gốc mở. Tôi làm gì?

— Sẽ
nguồn

26

Âm thanh như bạn đã bắt đầu ở đó, anh bạn.

— ta.speot.is

4

Bây giờ bạn hiểu tầm quan trọng của sao lưu. Làm điều đó thường xuyên.

— Juliano

Ít nhất anh ta không chmod từ gốc. Đó là một thảm họa đầy đủ. Ít nhất rm -rf từ root cung cấp cho bạn nhiều dung lượng đĩa hơn và chuẩn bị cho bạn cài đặt lại toàn bộ hệ thống, chmod chỉ để lại một mớ hỗn độn thực sự khó phục hồi bởi bất cứ thứ gì ngoài cài đặt lại hệ thống hoàn chỉnh. Cỏ có màu nâu ở hai bên hàng rào, nhỉ?

— Phòng thí nghiệm Fiasco

10

Hầu hết mọi thứ trong / bin / nên được sở hữu bởi root: root, vì vậy nếu bạn chạy phần sau, bạn có thể sửa quyền sở hữu trên các tệp đó:

chown root:root -R /bin/

Bạn cũng có thể muốn đảm bảo bit setuid được đặt đúng / bin / su, bạn có thể sửa bằng cách sau:

chmod 4755 /bin/su

— epic9x
nguồn

1

Trên Ubuntu, điều đặc biệt quan trọng là làm tương tự với sudo. Tôi không nghĩ rằng mật khẩu gốc thậm chí được đặt theo mặc định? Nhân tiện, tôi thực sự khuyên bạn nên thực sự sử dụng sudo thay vì root shell. Nửa giây cần để gõ sudo thường dừng các lỗi như vậy trong các bản nhạc. Chỉ cần làm việc trong một vỏ gốc sẽ dễ bỏ lỡ hơn ...

— Bernd Haug

4

paste.ubfox.com/362468 là "ls -l / bin" từ máy tính để bàn Ubuntu 9.10 của tôi. Mặc dù tôi có thể không cài đặt chính xác các tệp giống như bạn, nhưng ít nhất nó sẽ cung cấp cho bạn một gợi ý hay về những tệp nào cần quyền đặc biệt.

— andol

@Bernd: Mặc dù tôi không làm công việc quản trị viên nhiều như vậy, tôi đã nhận thấy rằng tôi sudo ít những thứ ngu ngốc hơn tôi làm root. Tôi có thể không bao giờ sử dụng mật khẩu root nữa. (Và, không, không có mật khẩu gốc mặc định trên Ubuntu và tôi không nghĩ rằng có một mật khẩu trên MacOSX.)

— David Thornley

@David: Chắc chắn không có mật khẩu gốc mặc định trên OS X và việc đặt mật khẩu chủ yếu là một lỗi, IMO. Hầu như luôn luôn có một cách khác, cách tốt hơn. Vấn đề là máy Mac không quá an toàn để bắt đầu; Tôi hy vọng sẽ thấy nhiều 'niềm vui' khi họ có cơ sở cài đặt lớn hơn để tạo ra các khách hàng RK, Virii, Botnet và c có lãi.

— Bernd Haug

36

Người dùng lại

chown 0:0 /bin/rpm && rpm -qa | xargs rpm --setugids

Người dùng Debian / Ubuntu:

chown 0:0 /bin/*  /usr/bin/*
chown daemon:daemon /usr/bin/at
chown 0:utmp /usr/bin/screen
chmod 02755 /usr/bin/screen
chmod u+s /bin/fusermount /bin/mount /bin/su /bin/mount
chmod u+s /usr/bin/sudo /usr/bin/passwd
screen

Trong khi màn hình đang chạy, hãy thực hiện việc này ít nhất hai lần:

dpkg --get-selections | awk '{ if ($2 == "install") print $1}' \
    | xargs apt-get install --reinstall --

Trả rất quan tâm sát sao đến đầu ra bởi vì nếu nó than phiền về một cái gì đó có các điều khoản sai, bạn nên sửa chữa nó trên một cửa sổ màn hình.

Khóa học sự cố trong màn hình:

Control+A     - command key
Control+A a   - emit a control+A
Control+A n   - next "screen"
Control+A c   - create "screen"

Người dùng Solaris:

Bạn đang đụ.

pkgchk -R / -f -a

sẽ thiết lập lại tất cả các quyền, nhưng setuid-ness vẫn sẽ bị hỏng. Sử dụng một bản sao lưu hoặc một máy năng lượng mặt trời khác để tìm kiếm các tập lệnh và tập tin setuid / setgid và sửa chúng bằng tay.

Điều quan trọng về BACKUPS

Là bạn có thể phục hồi chúng, không phải là bạn lấy chúng.

Những người khác đã cho bạn lời khuyên để sao lưu, nhưng tôi muốn thêm rằng bạn nên thử nghiệm chúng. Nếu bạn đang sử dụng một hệ thống không trộn lẫn, không có lý do gì mà bạn không thể đổ các tệp vào máy khác theo định kỳ và đảm bảo mọi thứ đều hoạt động.

— geocar
nguồn

Người dùng FreeBSD: sẽ không bao giờ mắc phải loại sai lầm này;)

— einstiien

10

@einstiien Yep, người dùng FreeBSD đi thẳng vào rm -rfsân khấu.

— grawity

@grawity: lol, một trong những tốt.

— einstiien

Người dùng Solaris kém :(

— Mircea Chirea

3

Xin lưu ý rằng các cờ set-uid trên bất kỳ nhị phân bị ảnh hưởng nào cũng có thể bị xóa; đây là một tính năng bảo mật của chown. Kiểm tra với một số hệ thống khác nhị phân nào có cờ set-uid hoặc set-gid và chắc chắn cũng đặt chúng trên nhị phân của bạn.

— Teddy
nguồn

3

Tôi sẽ giải thích chi tiết về việc sử dụng RPM để thiết lập lại quyền truy cập tệp, nhưng tôi đã tìm thấy một trang web có nhiều thông tin hơn . Nó cũng đề cập rằng Ubuntu / Debian (nói chung là .debs) không hỗ trợ nó.

Nhưng nói chung, tùy chọn mà bạn tìm kiếm sẽ nằm dọc theo dòng:

rpm --setugids {packagename}

— Coops
nguồn

Đây là trên một hệ thống Ubuntu, như được chỉ định bởi các thẻ. Điều này có nghĩa là dpkg và .DEB được sử dụng thay vì vòng / phút và .RPM

— Kevin M

2

Nếu đây là một hệ thống debian, tôi có khả năng cài đặt lại mọi thứ.

— ptman
nguồn

0

bạn có một bản sao lưu làm việc không? khi có, khôi phục thư mục bin của bạn.

mặt khác, hãy nhìn vào một hộp khác nơi bạn đã cài đặt cùng một phiên bản ubfox và chownvới những gì bạn tìm thấy trên bản cài đặt đang hoạt động.

— Cơ đốc giáo
nguồn

0

thử điều này: tìm tất cả dữ liệu www trong thư mục / bin

# find /bin -user www-data

sau đó thay đổi dữ liệu www trở lại người dùng ban đầu

# find /bin -user www-data -exec chown ORiginalUser {} \;

# then change www-data back to oringal group
# find /bin -group www-data -exec chgrp originaluser {} \;

— squillman
nguồn

0

Cảm ơn tất cả các phản hồi tuyệt vời, mọi thứ dường như đã được sửa chữa.

/ bin / su đã hoạt động khi chmod'd thành 4755 (không hiểu tại sao chown thay đổi bit suid)

tôi đã không thông báo nhưng nó cũng bắt đầu hoạt động thông qua thư mục / home nhưng đó là một sửa chữa đủ dễ dàng (chỉ cần đặt user: group thành người dùng cho mỗi dir)