Buộc chủ sở hữu trên các tệp và thư mục đã tạo


21

Tôi có một thư mục chứa dữ liệu được chia sẻ giữa một số người dùng. Truy cập vào thư mục này và bất cứ điều gì bên dưới, sẽ được kiểm soát bởi nhóm của thư mục, sẽ được thêm vào người dùng trong câu hỏi. Như vậy tôi đã tạo thư mục "nhóm dính" chmod g+s. Thư mục sẽ chứa cấu trúc cây với các thư mục và tệp, với tổng số lượng tệp có thể là vài triệu. Các tệp sẽ khá nhỏ, tôi không dự đoán bất cứ thứ gì lớn hơn 50MB.

Vấn đề của tôi là chủ sở hữu của tệp hoặc thư mục vẫn là người dùng đã tạo ra nó. Như vậy, ngay cả khi tôi nên xóa người dùng đó khỏi nhóm truy cập, tôi sẽ không xóa hoàn toàn quyền truy cập của anh ta.

Vì thế:

Có các tùy chọn khác mà tôi đã bỏ lỡ để đảm bảo rằng tất cả các tệp và thư mục con có cùng chủ sở hữu không?

Tôi hy vọng tôi có thể định kỳ lướt qua toàn bộ thư mục với một cron-job, nhưng điều đó gây cho tôi là không hiệu quả đối với những gì về cơ bản là lệnh một lần pr-file.

Tôi đã tìm thấy một ví dụ sử dụng INotify nhưng điều đó gây cho tôi sự bảo trì cao, vì nó đòi hỏi phải có kịch bản.

Tôi chưa thể biết liệu ACL có thể giúp tôi sở hữu bắt buộc hay không.

Có cách nào thông minh hơn để làm điều này?

Điều tôi muốn là có một thư mục có thể được chia sẻ bằng cách thêm một nhóm vào người dùng. Bất cứ điều gì được tạo trong thư mục này đều kế thừa lược đồ cấp phép từ cha mẹ của nó. Nếu có một cách tốt hơn những gì tôi đang cố gắng, thì tôi là tất cả.


Tôi không nghĩ tôi đã hiểu những gì bạn đang cố nói với tôi. Bạn có thể xây dựng?
Martin Nielsen

Để thiết lập tất cả các tệp và thư mục con có cùng nhóm & quyền sở hữu, tại sao không sử dụng chown -hR owner:group?
Pandya

Có thể, nhưng vì các tệp mới luôn được tạo và chúng tôi đang nói về các tệp trong hàng triệu, nên sẽ yêu cầu một công việc định kỳ lướt toàn bộ thư mục theo định kỳ. Trừ khi tôi đang thiếu một số điểm?
Martin Nielsen


Tôi thực sự đã đọc lướt câu hỏi đó trước khi tạo câu hỏi này. Nó dường như không giải quyết làm thế nào để buộc chủ sở hữu đối với một người dùng cụ thể.
Martin Nielsen

Câu trả lời:


12

Đặt chủ sở hữu mặc định "tự động" sẽ yêu cầu một thư mục setuidhoạt động như thế nào setgid. Tuy nhiên, trong khi điều này có thể được cấu hình trên FreeBSD, các hệ thống UNIX & Linux khác chỉ cần bỏ qua u+s. Trong trường hợp của bạn, tuy nhiên, có thể có một giải pháp khác.

Điều tôi muốn là có một thư mục có thể được chia sẻ bằng cách thêm một nhóm vào người dùng. Bất cứ điều gì được tạo trong thư mục này đều kế thừa lược đồ cấp phép từ cha mẹ của nó. Nếu có một cách tốt hơn những gì tôi đang cố gắng, thì tôi là tất cả.

Vì vậy, về cơ bản, từ những gì tôi thấy, bạn muốn kiểm soát quyền truy cập vào một thư mục bằng cơ chế nhóm. Tuy nhiên, điều này không yêu cầu bạn hạn chế các quyền trong toàn bộ cấu trúc thư mục. Trên thực tế, --xbit thực thi thư mục có thể chỉ là những gì bạn cần. Tôi sẽ cho bạn một ví dụ. Giả sử răng...

  • Nhóm kiểm soát truy cập vào group_dirthư mục là ourgroup.
  • Chỉ những người trong ourgroupnhóm có thể truy cập group_dir.
  • user1user2thuộc về ourgroup.
  • Ô mặc định là 0022.

... Hãy xem xét các thiết lập sau:

drwxrws---    root:ourgroup   |- group_dir/
drwxr-sr-x    user1:ourgroup  |---- group_dir/user1_submission/
drwxr-sr-x    user2:ourgroup  |---- group_dir/user2_submission/
-rw-r--r--    user2:ourgroup  |-------- group_dir/user2_submission/README

Ở đây, giả sử mọi mục được tạo bởi chủ sở hữu của nó.

Bây giờ, trong thiết lập này:

  • Tất cả các thư mục có thể được duyệt tự do bởi tất cả mọi người trong ourgroup. Bất cứ ai trong nhóm cũng có thể tạo, di chuyển, xóa các tệp ở bất kỳ đâu bên trong group_dir(nhưng không sâu hơn).
  • Bất cứ ai không tham gia ourgroupsẽ bị chặn tại group_dir, và do đó sẽ không thể thao túng bất cứ điều gì theo nó. Chẳng hạn, user3(không phải là thành viên của ourgroup), không thể đọc group_dir/user2_submission/README(mặc dù anh ta có r--quyền đối với chính tệp đó).

Tuy nhiên, có một vấn đề nhỏ trong trường hợp này: vì có ô thông thường, các mục được tạo bởi người dùng không thể bị thao túng bởi các thành viên khác trong nhóm. Đây là nơi ACL xuất hiện. Bằng cách đặt quyền mặc định, bạn sẽ đảm bảo mọi thứ đều ổn dù giá trị umask:

$ setfacl -dRm u::rwX,g::rwX,o::0 group_dir/

Cuộc gọi này đặt:

  • Quyền mặc định rw(x)cho chủ sở hữu.
  • Quyền mặc định rw(x)cho nhóm.
  • Không có quyền theo mặc định cho những người khác. Lưu ý rằng vì dù sao những người khác không thể truy cập group_dir, nên thực sự không có vấn đề gì về quyền của họ bên dưới nó.

Bây giờ, nếu tôi tạo một mục như user2:

$ touch group_dir/user2_submission/AUTHORS
$ ls -l group_dir/user2_submission/AUTHORS
rw-rw----    user2:ourgroup    group_dir/user2_submission/AUTHORS

Với ACL này, chúng ta có thể thử xây dựng lại cấu trúc trước đây của mình:

drwxrws---+    root:ourgroup   |- group_dir/
drwxrws---+    user1:ourgroup  |---- group_dir/user1_submission/
drwxrws---+    user2:ourgroup  |---- group_dir/user2_submission/
-rw-rw----+    user2:ourgroup  |-------- group_dir/user2_submission/README

Ở đây một lần nữa, mỗi mục được tạo bởi chủ sở hữu của nó.

Ngoài ra, nếu bạn muốn cung cấp thêm một chút sức mạnh / bảo mật cho những người sử dụng thư mục, bạn có thể muốn xem xét một chút dính. Ví dụ, điều này sẽ ngăn không cho user1xóa user2_submission(vì anh ta có -w-quyền trên group_dir):

$ chmod +t group_dir/

Bây giờ, nếu user1cố gắng xóa user2thư mục của anh ta, anh ta sẽ nhận được một sự đáng yêu Operation not permitted. Tuy nhiên, lưu ý rằng trong khi điều này ngăn chặn sửa đổi cấu trúc thư mục trong group_dir, các tệp và thư mục bên dưới vẫn có thể truy cập được:

user1@host $ rm -r user2_submission
Operation not permitted

user1@host $ cat /dev/null > user2_submission/README

user1@host $ file user2_submission/README
user2_submission/README: empty (uh-oh)

Một điều nữa cần tính đến là các ACL chúng tôi đã sử dụng thiết lập quyền mặc định . Do đó, chủ sở hữu của một mặt hàng có thể thay đổi các quyền liên quan đến nó. Chẳng hạn, user2hoàn toàn có thể chạy ...

$ chown g= user2_submission/ -R
or
$ chgrp nobody user2_submission -R

... do đó làm cho thư mục gửi đầy đủ của anh ấy không có sẵn cho bất cứ ai trong nhóm.

Tuy nhiên, vì ban đầu bạn sẵn sàng cấp rwsquyền truy cập đầy đủ cho bất kỳ ai trong nhóm, tôi cho rằng bạn tin tưởng những người dùng này và bạn sẽ không mong đợi quá nhiều hoạt động độc hại từ họ.


ACL sẽ ghi đè các quyền mặc định? Ví dụ: nếu tôi đặt $ setfacl -dRm u :: r, g :: rwX, o :: 0 group_dir / thay vào đó, chỉ cho phép các thành viên của nhóm tạo tệp, chủ sở hữu có thể chỉnh sửa các tệp trong khi không trong nhóm? Điều quan trọng là người dùng chỉ có thể chỉnh sửa các tệp nếu họ là thành viên của nhóm, bất kể chủ sở hữu là ai.
Martin Nielsen

Bạn không cần phải xóa tất cả các quyền từ chủ sở hữu cho điều đó. Nếu nhóm có quyền ghi trên tệp, các thành viên nhóm sẽ có thể chỉnh sửa tệp. Chủ sở hữu sẽ chỉ là "một chút đặc quyền". ACL không phải luôn ghi đè các quyền mặc định (xem về các quyền hiệu quả của ACL).
John WH Smith

Vấn đề là người dùng không nên có quyền riêng tư, chỉ có nhóm nên. Chủ sở hữu nên cho tất cả ý định và mục đích hoàn toàn không được ưu tiên trừ khi anh ấy / cô ấy ở trong nhóm.
Martin Nielsen

Về cơ bản, dù sao đi nữa, bất kỳ ai không thuộc nhóm đều không được ưu tiên, vì anh ta sẽ không thể vào group_dirvị trí đầu tiên, bất kể anh ta có sở hữu tệp này hay không. "Đặc quyền" thực sự duy nhất mà chủ sở hữu có là anh ta có thể thay đổi các quyền của sáng tạo của nó (mà tôi đã nêu chi tiết hơn một chút trong câu trả lời của mình).
John WH Smith

1
Tuyệt đối không. Các group_dirthư mục được sở hữu bởi root:ourgroupvới -rwxr-x---, có nghĩa là chỉ có root và các thành viên ourgrouptruy cập có thể nó, tức là làm gì với các tập tin dưới nó. Nếu bạn không có --xquyền trên một thư mục, bạn không thể truy cập một tệp trong đó, ngay cả khi bạn có quyền của chính tệp đó.
John WH Smith

6

Có một cách thông minh hơn để làm điều này. Nó sử dụng kết hợp set-gid và acls mặc định . Rõ ràng, bạn sẽ cần một hệ thống tập tin kích hoạt acl. Giả sử thư mục bạn muốn chia sẻ là tại /var/grpdirvà các thành viên của nhóm sharingsẽ có thể truy cập nó.

chown root:sharing /var/grpdir
chmod 2770 /var/grpdir #other can't read or traverse into the directory, set-gid is set
setfacl -d -m u::rwX,g::rwX,o::0 /var/grpdir

ACL mặc định được kế thừa bởi các thư mục con được tạo trong một thư mục có ACL mặc định. Vì vậy, điều này có nghĩa là, bất kỳ tệp nào được tạo /var/grpdirsẽ có nhóm được đặt sharingtheo bit setgid của thư mục. Ngoài ra, nó sẽ kế thừa các acls mặc định, sẽ ghi đè lên các kiểu đầu tiên mặc định của linux, vì chúng tôi không chỉ định ACL với các nhóm hoặc người dùng cụ thể. Điều này có nghĩa là tất cả các tệp sẽ được tạo với quyền sở hữu <user>:sharingvà quyền rw-rw----. Các thư mục sẽ giống nhau, ngoại trừ chúng cũng sẽ có các ACL mặc định của riêng chúng được đặt giống như cha mẹ của chúng ( /var/grpdir) và tất nhiên có các bit thực thi được đặt cho người dùng và nhóm. Nếu bạn xóa người dùng khỏi sharingnhóm, họ sẽ không thể truy cập vào thư mục (cũng không có bất kỳ tệp nào trong đó, ngay cả khi họ sở hữu chúng).

Không giống như định kỳ sửa quyền với cronjob, quyền luôn được đồng bộ hóa, vì chúng được cập nhật nguyên tử với các tệp và thư mục mới được tạo. Giải pháp này là nhẹ; không có trình tiện ích nào là cần thiết và không có đột biến nào đối với IO trong khi sửa quyền trong một cú trượt.


Vì vậy, tôi có hiểu chính xác điều này không: ACL sẽ ghi đè các quyền hệ thống tệp bình thường nếu bạn không chỉ định người dùng hoặc nhóm?
Martin Nielsen

1
Không, họ không sửa đổi bất kỳ quyền nào đã được đặt trên một tệp. Khi một thư mục có acls quyền mặc định được đặt và một tệp hoặc thư mục được tạo trong thư mục đó, tệp / thư mục MỚI sẽ được cấp quyền mặc định như được chỉ định. Các tệp được sao chép / di chuyển vào thư mục vẫn giữ quyền của chúng, cũng như các tệp tồn tại trong thư mục trước khi các acls được đặt. Ngoài ra, chmod và chown vẫn có thể được sử dụng như bình thường để sửa đổi quyền sở hữu và quyền sau khi tệp được tạo
sirlark

2

Tôi không biết bất kỳ cách tốt để làm điều này. Cách sạch nhất về mặt kỹ thuật sẽ là một hệ thống tệp FUSE thực hiện điều đó. Tất nhiên, rất nhiều công việc nếu chưa có ai làm điều đó.

Lựa chọn thay thế:

  1. Sử dụng samba. samba có force usertham số. Bạn có thể xuất một thư mục cục bộ và gắn kết nó cục bộ. Không làm cho truy cập nhanh hơn nhưng có thể được chấp nhận vì chỉ có kết nối mạng vòng lặp.

  2. Sử dụng hệ thống tệp không phải Linux như FAT32. Điều này phải được cấu hình cho một người dùng nhất định để gắn kết nó. Các quyền truy cập phải được xử lý bởi thư mục cha.


0

Tôi chưa nghe thấy bất kỳ cách nào để tự động thay đổi quyền sở hữu tệp sao cho chủ sở hữu tệp bị thay đổi khi tệp được chuyển vào một thư mục nhất định. Điều gần nhất là bit dính, nhưng có vẻ như bạn đã chỉ ra rằng quyền sở hữu nhóm là không đủ, quyền sở hữu người dùng thực tế phải thay đổi.

Trong trường hợp đó, tôi nghĩ rằng đặt cược tốt nhất của bạn là công việc định kỳ với cờ -R chown, như Pandya đã đề cập. Đặt nó trên một cron để chạy mỗi phút hoặc mỗi năm phút.

Nếu bạn có thể giải thích cách người dùng của bạn đang sử dụng điều này, có thể có một số giải pháp tốt hơn.

ACL có thể giúp bạn kiểm soát hạt tốt hơn đối với người được phép làm gì, nó sẽ không tự động thay đổi quyền sở hữu tệp thực tế cho bạn. Tôi nghĩ rằng bạn cần có được một cái nhìn cao hơn và đánh giá / thiết kế lại giải pháp của bạn trên cơ sở đó.


0

Bạn có thể sử dụng các công cụ inotify và viết một tập lệnh bash đơn giản như dưới đây. Inotify sẽ để mắt đến web thư mục và làm một cái gì đó bất cứ khi nào một sự kiện như tạo dir sẽ xảy ra trong thư mục web. Có nhiều sự kiện hiện có. Bạn có thể google nó hoặc có thể đã xem trên trang web này

while inotifywait -m -e CREATE web; do echo "A new directory has been created"; done
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.