Tôi có thể chuyển quyền của người dùng trên các máy tính cho ổ cứng ngoài ext4 không?


16

Tôi có ổ đĩa USB 3 ngoài (dung lượng 2TB) rất có thể sẽ được chuyển từ máy này sang máy khác. Đĩa có bảng phân vùng GUID và phân vùng ext4. Tôi không thể ghi vào đĩa trừ khi tôi nâng quá trình ( sudo).

Đến bây giờ tôi đang nghĩ đến việc thử một hoặc cả hai điều sau đây và muốn biết nhược điểm của từng -

  1. chmod 777 /mnt/externalDrive
  2. chown nobody:nogroup /mnt/externalDrive

Nếu tôi cấp quyền 777 và user1 (UID: 1005) ghi vào nó và sau đó tôi chuyển đĩa sang một máy tính khác trong đó user7 là UID: 1005, điều gì xảy ra? User7 có trở thành chủ sở hữu của tệp trên máy tính đó không? Dường như với tôi rằng tôi sẽ định kỳ phải chạy chown -R nobody:nogroup /mnt/externalDrivetrên đĩa.

Có bất cứ điều gì tôi đang xem xét một thực hành xấu rõ ràng? Đĩa rất có thể sẽ chứa video, nhạc và hình ảnh mà không cần phải bảo vệ như một số dữ liệu tài chính.


Tôi không chắc chắn nếu tôi theo bạn. Bạn đã thử thiết lập quyền trong ổ đĩa ngoài?
Ramesh

1
Đúng. Đó có phải là một điều tốt?
Chúa ơi.

Câu trả lời:


19

Đó là vấn đề với các hệ thống nhiều người dùng, đặc biệt là nếu bạn có nhiều hơn một trong số họ. ;) Không có cách nào thực sự tốt để làm những gì bạn muốn. Phương pháp tiếp cận đến với tâm trí sẽ là

  • có cùng UID cho tài khoản của bạn trên mọi máy bạn đang sử dụng ổ đĩa ngoài (thực sự không khả thi, vì hầu hết có lẽ không phải tất cả các máy đều nằm dưới sự kiểm soát của bạn)
  • sử dụng một hệ thống tệp mà không biết về cấu hình của chủ sở hữu / nhóm (FAT hoặc NTFS xuất hiện trong tâm trí, nhưng, aaah, không)

Cách tiếp cận hiệu quả nhất sẽ trở lại với các thông lệ. Trên hầu hết (ít nhất) các hệ thống Linux, tồn tại một số nhóm thường có các GID phổ biến. Ví dụ, sẽ userscó GID 100trên hầu hết các bản phân phối Linux. Nếu bạn có thể quản lý để có tài khoản người dùng tương ứng của mình trong nhóm này, bạn có thể

  1. làm cho tất cả các tệp và thư mục trên ổ đĩa của bạn thuộc sở hữu của nhóm này
  2. bằng cách nào đó quản lý để có quyền nhóm phù hợp trên các tệp và thư mục đó
  3. bằng cách nào đó quản lý để có các tệp mới được tạo với sự tôn trọng quyền sở hữu nhóm thích hợp. quyền.

Điểm thứ nhất và thứ hai rất dễ thực hiện ( chown, chmod). Điểm thứ ba nhận được một chút khó khăn hơn.

Phần "sở hữu nhóm" tương đối dễ dàng: Bạn có thể đặt bit SGID trên tất cả các thư mục trên ổ đĩa. Bit SGID được áp dụng cho các thư mục yêu cầu kernel hoạt động theo cách BSDish: BSD làm cho mọi tệp / thư mục được tạo trong một thư mục cụ thể thuộc sở hữu của nhóm không phải bởi nhóm chính của quy trình tạo tệp / thư mục (như Linux), nhưng bởi chủ sở hữu của thư mục cha.

Các bit cho phép là một chút khó khăn. Quyền của các tệp / thư mục mới được tạo (trong số các tệp khác) bị ảnh hưởng bởi umask, mặt nạ bit cho biết bit nào không được đặt nếu không được nêu rõ ràng. umaskVí dụ 022, một giá trị chung là , các bit ghi cho »nhóm« và »các nhóm khác« thường không nên được đặt. Bạn có thể thay đổi umaskthành 002, nói rằng bạn không muốn xóa quyền ghi cho nhóm nhưng nhược điểm là bạn không thể đặt giá trị này dựa trên thư mục và bạn thường không muốn có quyền ghi cho nhóm chính của bạn được đặt cho mọi tệp bạn tạo.

Điều này có thể được giải quyết bằng ACL: Trong một ACL, bạn có thể đặt một bộ maskdefaultquyền, áp dụng cho tất cả các tệp và thư mục được tạo trong một thư mục có bộ ACL này. Vì vậy, một giải pháp khả thi cho vấn đề của bạn sẽ là

  • đảm bảo bạn là thành viên của một nhóm chung trên tất cả các hệ thống bạn muốn sử dụng ổ đĩa ngoài của mình trên
  • làm cho tất cả các tệp và thư mục trên ổ đĩa của bạn thuộc sở hữu của nhóm này và đặt bit SGID trên tất cả các thư mục
  • thay đổi ACL của tất cả các thư mục để bao gồm mặt nạ và quyền mặc định cho hạt nhân tạo mọi tệp / thư mục mới với quyền ghi được đặt cho nhóm.

Xem setfacl(1)acl(5)để biết thêm chi tiết.


1
Có một bản vá nổi xung quanh cho ánh xạ gid và gid của anh ấy trong ext4, spinics.net/lists/linux-fsdevel/msg57240.html , nhưng tôi không nghĩ rằng nó đã đi qua ...
Rmano

10

một câu hỏi tương tự khác và bindfs được đề xuất ở đó:

mkdir /home/$user/sda1
bindfs -u $user -g $group /mnt/sda1 /home/$user/sda1

Người dùng OSX đề xuất noownerstùy chọn gắn kết được mô tả như thế này:

Bỏ qua trường sở hữu cho toàn bộ khối lượng. Điều này khiến tất cả các đối tượng xuất hiện dưới dạng sở hữu bởi ID người dùng 99 và ID nhóm 99. ID người dùng 99 được hiểu là ID người dùng hiệu quả hiện tại, trong khi ID nhóm 99 được sử dụng trực tiếp và dịch thành '`unknown' '.


bindfs là khá chậm. Có lẽ bởi vì đó là một hệ thống tập tin FUSE.
Navin

4

Chủ sở hữu và nhóm của một tập tin được lưu trữ dưới dạng số. Vì vậy, tệp sẽ được sở hữu bởi uid = 1005, bất kể người dùng nào (hoặc không có ai) trên hệ thống mà nó được kết nối.

Thay đổi người dùng / nhóm thành không ai sẽ không khắc phục vấn đề của bạn. Sau đó, chỉ người dùng (hoặc thành viên của nhóm không ai) mới được phép truy cập các tệp.

Thật không may, tôi không nghĩ có một cách để vô hiệu hóa kiểm tra quyền trên ext4. Xem, ví dụ, Có thể vô hiệu hóa quyền truy cập tệp trên hệ thống tệp ext3 hoặc ext4 không?


2

Andreas Wiese nói rằng nếu bạn có id nhóm chung trên tất cả các máy chủ, bạn có thể giải quyết vấn đề của mình bằng setgidbit và ACL

Tôi đặt câu hỏi Id nhóm được xác định trước trên các bản phân phối Linux?

Sau khi nghiên cứu riêng phát hiện ra rằng nhóm đó tồn tại trên tất cả các distro cảm ứng: sysid chia sẻ nhóm 3trên Debian, Ubuntu, RedHat, Fedora, CentOS, Suse, FreeBSD, OpenBSD, NetBSD, MacOSX, Solaris.

Với cái này:

$ sudo chgrp -R sys /mnt/data/dir
$ sudo chmod -R g+s /mnt/data/dir
$ sudo setfacl -R -m g:sys:rwx /mnt/data/dir
$ sudo setfacl -R -d -m g:sys:rwx /mnt/data/dir

và hương vị của điều này:

$ sudo adduser user sys

bạn usercó thể đọc / ghi bất kỳ tập tin nào trên /dir.

Hầu hết các công việc có thể làm setgidmột chút nhưng tiếc là bạn thường có ít quyền kiểm soát umask. Vì vậy, ACL được sử dụng để cung cấp giải pháp hoàn chỉnh.

Xem thêm:

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.