Quyền chỉ bị từ chối đối với một tệp duy nhất trong thư mục là người dùng root trên hệ thống tệp ext3 trong Hệ điều hành RAIDoder


9

Tôi có một hộp ReadyNAS có tên là "dung lượng lưu trữ" mà tôi tin là dựa trên Debian. Tôi có thể ssh vào nó như root. Tôi đang cố gắng cấu hình lại máy chủ web, nhưng tôi đang gặp vấn đề về quyền truy cập tệp mà tôi không hiểu. Tôi không thể làm bất cứ điều gì với /etc/frontview/apache/apache.pemngay cả gốc! Dường như không có bất kỳ quyền đặc biệt nào so với các tệp khác trong cùng thư mục và tôi có thể làm việc với các tệp đó.

storage:~# whoami 
root
storage:~# cd /etc/frontview/apache/   
storage:/etc/frontview/apache# ls -lah apache.pem*         
-rw-------    1 admin    admin        4.0k Jul 10  2013 apache.pem
-rw-------    1 admin    admin        4.0k Jun  9 05:57 apache.pem.2017-02-04
-rw-------    1 admin    admin        1.5k Jun  9 05:57 apache.pem.orig
storage:/etc/frontview/apache# touch apache.pem            
touch: creating `apache.pem': Permission denied
storage:/etc/frontview/apache# touch apache.pem.2017-02-04 
storage:/etc/frontview/apache# rm -f apache.pem
rm: cannot unlink `apache.pem': Operation not permitted

Điều gì đặc biệt về tập tin này mà nó không thể được chạm vào? Tôi không thể xóa nó. Tôi không thể thay đổi các quyền trên đó. Tôi không thể thay đổi chủ sở hữu của nó.

Các thư mục có vẻ là tốt. Nó có không gian còn lại, nó không được gắn chỉ đọc. Trong thực tế, tôi có thể chỉnh sửa các tập tin khác trong cùng thư mục.

# ls -ld /etc/frontview/apache
drwxr-xr-x    8 admin    admin        4096 Jun  9 05:44 /etc/frontview/apache
# df /etc/frontview/apache
Filesystem           1k-blocks      Used     Available Use% Mounted on
/dev/hdc1            2015824        504944   1510880   26% /

Xin vui lòng hiển thị đầu ra của ls -ld /etc/frontview/apachedf /etc/frontview/apache. Có lẽ thư mục nằm trên một không gian đĩa được gắn ro?
Ned64

Tôi đã thêm thông tin đó vào câu hỏi. Tất cả có vẻ tốt với tôi. Trong mọi trường hợp, nếu đó là vấn đề, tôi sẽ không nghĩ mình có thể chỉnh sửa mọi tập tin khác trong thư mục đó.
Stephen Ostermiller

@RunCMD Tôi đã thêm thông tin cụ thể hơn vào tiêu đề và thẻ. Hệ thống tập tin được liệt kê là ext3, vì vậy ext3 sẽ xuất hiện để hỗ trợ bất biến # mount::/dev/hdc1 on / type ext3 (rw,noatime)
Stephen Ostermiller

1
Solaris không hỗ trợ ext3 hay ARM cpu, vì vậy có lẽ không dựa trên Solaris.
alanc

1
Tôi loại bỏ Solaris khỏi câu hỏi. Khi đọc thêm, nó có thể dựa trên Debian Etch.
Stephen Ostermiller

Câu trả lời:


9

Tôi chỉ tìm thấy vấn đề. Thuộc tính "bất biến" đã được đặt trên tệp đó. lskhông hiển thị nó. Bạn cần một lệnh khác để xem nó:

# lsattr apache.pem*
----i--------- apache.pem
-------------- apache.pem.2017-02-04
-------------- apache.pem.orig

Khi tôi xóa bit bất biến, tôi có thể chỉnh sửa tệp đó:

# chattr -i apache.pem
# touch apache.pem

1
Tôi đã nhấp vào câu hỏi này trong "câu hỏi mạng nóng" để bảo bạn kiểm tra các thuộc tính mở rộng, nhưng tôi đoán bạn đã làm rồi. (IDK tại sao GNU lskhông có tùy chọn liệt kê các thuộc tính. Tôi quên, nhưng thậm chí có thể cả hệ thống gọi truy vấn chúng không khả dụng, do đó, có thể dễ dàng hơn khi triển khai chúng trong một tiện ích riêng biệt.)
Peter Cordes

@PeterCordes Tôi đồng ý. Tôi chắc chắn rằng tôi đã thiết lập bit đó sau khi Googling một cái gì đó như "dừng nâng cấp từ tập tin ghi đè", nhưng đó là cách đây nhiều năm và tôi rõ ràng đã quên làm như vậy. Sẽ thật tuyệt nếu lshiển thị bit đó hoặc nếu bất kỳ lệnh nào khác tôi sử dụng có thông báo lỗi hữu ích (và cụ thể) hơn về lý do các quyền bị từ chối.
Stephen Ostermiller

Tất cả touchđều biết rằng hệ thống gọi nó đã cố gắng ( open("apache.pem", O_WRONLY|O_CREAT|..., 0666)) không thành công EACCESS. (Sử dụng strace -efile touch apache.pemđể xem các cuộc gọi hệ thống liên quan đến tập tin mà nó thực hiện). Như trang man cho cuộc gọi hệ thống đó nói , có nhiều lý do có thể xảy ra đối với EACCESS và nhiều trong số chúng liên quan đến các thư mục mẹ hơn là chính tệp. Viết mã để suy luận chính xác lý do tại sao một cuộc gọi hệ thống trả về lỗi nó sẽ cực kỳ khó khăn, vì các hệ thống tệp và hệ điều hành khác nhau là khác nhau ...
Peter Cordes

Dù sao, quy ước phổ quát là khi một cái gì đó không thành công, bạn tìm chuỗi lỗi cho mã lỗi ( errno) và in nó. (Sử dụng perrorchức năng thư viện chuẩn C hoặc tương đương). Đây là một trong những trường hợp hiếm hoi mà không phải lúc nào cũng đủ gợi ý để người dùng nhanh chóng tìm ra vấn đề, nhưng hầu hết thời gian nó hoạt động rất tốt. (Đặc biệt là khi kết hợp với stracetrong trường hợp có bất kỳ nghi ngờ về chính xác mà hoạt động sản xuất lỗi.) Đó là chưa hoàn hảo, nhưng nó có thể là nhiều tồi tệ hơn (cf. MS Windows nơi ở tốt nhất mà bạn nhận được một mã lỗi vào google.)
Peter Cordes

Chỉ chơi xung quanh chattr +ivà nhận thấy rằng rm foo(không có -f) lời nhắc : rm: remove write-protected regular file ‘foo’. Bởi vì faccessat(AT_FDCWD, "/var/tmp/foo", W_OK) = -1 EACCES (Permission denied). POSIX yêu cầu rmphải nhắc theo mặc định trước khi xóa các tệp được bảo vệ ghi và đó là lý do tại sao nó kiểm tra ở vị trí đầu tiên. Vì vậy, bạn sẽ nhận được một manh mối lớn nhanh hơn nếu bạn không sử dụng rm -f. : / access(3)yêu cầu kernel kiểm tra quyền như thể nó thực sự mở để ghi, vì vậy nó chọn ACL và thuộc tính.
Peter Cordes
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.