Tại sao thay đổi chủ sở hữu của một liên kết tượng trưng trong linux?


12

Trong linux, có thể thay đổi chủ sở hữu hoặc chủ sở hữu nhóm của một liên kết tượng trưng (symlink). Tôi đã tự hỏi tại sao ai đó muốn làm điều đó, vì quyền của một liên kết tượng trưng không được sử dụng khi truy cập một tệp thông qua nó.

Tôi chỉ có thể tưởng tượng một trường hợp sử dụng có thể hữu ích: cho phép người dùng xóa một liên kết tượng trưng trong một thư mục có bit dính.

Bạn có biết các trường hợp khác có thể hữu ích khi thay đổi chủ sở hữu hoặc chủ sở hữu nhóm của một liên kết tượng trưng không?

Câu trả lời:


6

Giả sử root đang làm việc trong một thư mục mà Eve có thể ghi vào. Có một tập tin footrong thư mục này cần được thay đổi để thuộc về Eve. Vì vậy, các loại gốc chown eve foo. Nhưng ngay trước khi root chạm Enter, Eve chạy ln -sf /etc/passwd foo. Bây giờ /etc/passwdthuộc về đêm giao thừa! Nếu root có thể chạy chown -h eve foođể đảm bảo không theo symlink, thì tác hại lớn nhất có thể xảy ra là một số tệp khác trong cùng thư mục đã được thay đổi để thuộc về Eve.

lchowncũng thuận tiện khi bạn thay đổi chủ sở hữu của cây thư mục. Bạn không cần phải lo lắng về việc vô tình ảnh hưởng đến một tệp bên ngoài cây vì bạn đã gọi chownvào một liên kết tượng trưng.


"Nếu root có thể chạy chown -h bob foo để đảm bảo không theo symlink, thì tác hại nhất có thể xảy ra là một số tệp khác trong cùng thư mục đã được thay đổi để thuộc về Eve.". Tôi đoán bạn có nghĩa là "chown -h eve foo". Các tập tin khác có thể được thay đổi, đó là liên kết tượng trưng phải không?
dùng368507

@ user5528 Tệp khác có thể không phải là một liên kết tượng trưng: Eve vẫn có thể chạy mv myfile foovà root sẽ thay đổi chủ sở hữu của myfile. Nhưng myfilephải là một tệp mà Eve có thể tạo hoặc di chuyển vào thư mục đó, nó không thể là bất kỳ tệp nào trên hệ thống.
Gilles 'SO- ngừng trở nên xấu xa'

2
Mặc dù thú vị và rõ ràng được người hỏi chấp thuận, tôi không thấy câu trả lời này giải quyết câu hỏi như thế nào. Có vẻ như nhiều hơn để giải thích lý do tại sao người ta có thể sử dụng chown -hnhư một biện pháp cảnh báo khi thay đổi quyền sở hữu một tệp không được coi là một liên kết tượng trưng, ​​nhưng vẫn có thể là (trường hợp cạnh, IMO). Nó không giải thích lý do tại sao người ta có thể muốn thay đổi quyền sở hữu một tệp trong thực tế dự định là một liên kết tượng trưng, ​​đó là những gì câu hỏi được hỏi.
Ivan X

Tại sao chownthay đổi chủ sở hữu của "một tệp bên ngoài cây" là tất cả những gì bạn đang thay đổi là chủ sở hữu của thư mục?
Melab

@Melab Khi bạn thay đổi chủ sở hữu của cây thư mục , tức là bỏ tiện ích chown -R, gọi cuộc gọi (l)chownhệ thống trên mỗi mục nhập thư mục. Nếu mục nhập thư mục là một liên kết tượng trưng thì bạn không được gọi cuộc gọi chownhệ thống trên đó vì điều đó sẽ ảnh hưởng đến mục tiêu của liên kết có thể nằm bên ngoài cây.
Gilles 'SO- ngừng trở nên xấu xa'

8

Apache có thể được cấu hình để theo các liên kết chỉ khi chủ sở hữu của liên kết khớp với chủ sở hữu của đích. Điều này có thể giúp ngăn người dùng tạo liên kết để truy cập web vào các tệp mà họ không sở hữu (ví dụ / etc / passwd).

... Vì vậy, giả sử bạn, với quyền root, muốn apache theo liên kết để hiển thị một logfile nào đó, được sở hữu bởi xymon hoặc thứ gì đó, nhưng bạn không muốn thư giãn bảo mật của apache bằng cách cho phép nó theo liên kết tượng trưng bất kể chủ sở hữu . Sau đó, bạn có thể muốn biến xymon thành chủ sở hữu của liên kết tượng trưng.


1
Đồng ý. Tôi biết nó không liên quan nhưng điểm của hành vi này trong apache là gì? Ý tôi là nếu người dùng có thể đọc tệp, tại sao lại phải đọc nó từ truy cập web? thx
user368507

Vâng, nó không chỉ là một người dùng địa phương đọc tệp; nếu apache có thể đọc nó, thì có khả năng mọi người đều có thể đọc nó. Và nếu một số lỗ hổng apache cho phép tạo ra một liên kết tượng trưng /etc/passwd, thì badguy có thể đã đọc quyền truy cập vào tệp đó mà không có bất kỳ quyền truy cập cục bộ nào khác - nhưng sẽ bị cản trở bởi liên kết được sở hữu bởi apache.
Lars Rohrbach

4

Câu trả lời đầu tiên dường như không nhấn vào câu hỏi và câu trả lời thứ hai chỉ áp dụng cho Apache.

Một điều tôi có thể nghĩ cho linux nói chung là người dùng bình thường chỉ có thể tạo liên kết cứng với liên kết tượng trưng nếu người dùng là chủ sở hữu của liên kết tượng trưng. Tại sao một người muốn tạo một liên kết như vậy, tôi không biết.

Một điều nữa là người dùng thông thường chỉ có thể thay đổi quyền sở hữu nhóm của tệp nếu người dùng sở hữu tệp đó (và cũng là thành viên của nhóm mà tệp đang được thêm vào.) Điều đó đặt ra câu hỏi về quyền sở hữu nhóm của một liên kết tượng trưng nào. Trong một tổ chức, nó có thể hữu ích như một thẻ để cho biết nhóm nào sẽ cần liên kết.

Ngoài ra, trên Ubuntu ít nhất, bất kỳ ai cũng có thể cập nhật dấu thời gian của một liên kết tượng trưng. Tuy nhiên, có thể có một số hệ thống chỉ cho phép chủ sở hữu. Dấu thời gian tốt cho một liên kết tượng trưng, ​​tôi không chắc, nhưng nó có thể cung cấp một số thông tin hữu ích về mức độ sử dụng của nó.

Chỉnh sửa: Tôi chỉ nhận ra một lý do khác tại sao quyền sở hữu sẽ quan trọng. Liên kết có thể nằm trong một thư mục dính, trong đó chỉ chủ sở hữu của tệp có thể xóa hoặc đổi tên nó.


0

Tôi có một chương trình nối vào tệp nhật ký. Các tệp nhật ký này được tạo hàng tháng với mỗi tên khác nhau. Thay vì để phần mềm tìm ra tên tệp chính xác, tôi sử dụng tên tệp "chung" (nói data.log) là liên kết tượng trưng chỉ đến tệp hiện tại cho tháng đó. Điều này được tự động hóa trên một công việc định kỳ.

Bây giờ khi một tệp mới hàng tháng được tạo, nó cần trỏ liên kết tượng trưng đến tệp mới. Nếu có xung đột quyền sở hữu / nhóm, phần mềm không thể thay đổi liên kết tượng trưng. Vì vậy, bạn cần quyền sở hữu / nhóm viết đặc quyền để thay đổi liên kết tượng trưng.


0

Nếu bạn muốn có một liên kết đến một tệp trên màn hình mở của bạn, liên kết tượng trưng phải nằm trong

"/ nhà / tên người dùng / Máy tính để bàn"

danh mục.

Và, chính liên kết tượng trưng phải có quyền sở hữu root: root (0: 0), nếu không thì liên kết không hoạt động.

(Ubuntu / Debian, v.v.)

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.