gcsfuse không mở được/dev/fuse: Quyền bị từ chối

Tôi đang chạy lệnh sau bên trong vùng chứa với tư cách là người dùng bình thường, không phải root

gcsfuse --foreground --debug_fuse --debug_fs --debug_gcs --debug_http my-bucket /data

Và nó hoạt động tại địa phương khi tôi bắt đầu container với --đặc quyền và đó là tốt.

Nhưng điều tương tự không hoạt động trên Cloud Run (khi sử dụng môi trường thực thi xem trước thế hệ thứ 2). Tôi nhận được lỗi sau đây:

2022-05-13 12:08:41.547 CEST gcs: 2022/05/13 10:08:41.546642 Req 0x1: -> ListObjects("") (46.897367ms): OK
13-05-2022 12:08:41.551 CEST /usr/bin/fusermount: không mở được /dev/fuse: Quyền bị từ chối
13-05-2022 12:08:41.551 CEST mountWithArgs: mountWithConn: Mount: mount: running /usr/bin/fusermount: thoát trạng thái 1

Tất cả các dòng nhật ký gỡ lỗi khác, HTTP, GCS, v.v. đều cho thấy mọi thứ đều hoạt động.

Tôi tạo người dùng của mình như thế này trong Dockerfile

CHẠY useradd -lmU joe\
  && mkdir -p /dữ liệu \
  && chown -R joe:joe /data
NGƯỜI DÙNG

Các tài liệu nói rằng tôi nên chạy gcsfuse với tư cách là người dùng sẽ sử dụng hệ thống tệp chứ không phải với quyền root, nhưng nó không hoạt động. Bất cứ ý tưởng những gì tôi đang làm sai?

Đối với cộng đồng đang tìm kiếm câu trả lời cho câu hỏi này:

Theo điều này câu trả lời, việc thêm -file-mode=777 -dir-mode=777 cùng với lệnh gcsfuse trong gcsfuse.sh để cho phép đọc/ghi bên trong thư mục được gắn của bộ chứa GCS sẽ là một tùy chọn nhưng vì Kohányi Róbert xác nhận rằng nó không phục vụ mục đích này vì lý do bảo mật. Tôi đào sâu hơn và tôi tìm thấy thông tin thực sự hữu ích này:

• Theo mặc định, tất cả các nút trong hệ thống tệp gcsfuse hiển thị dưới dạng thuộc sở hữu của UID và GID của chính quy trình gcsfuse, tức là người dùng người đã gắn hệ thống tập tin. 644 và 755 là các quyền mặc định cho tất cả các inode tệp và thư mục trong hệ thống tệp gcsfuse. Thay đổi chế độ inode (sử dụng chmod(2) hoặc tương tự) không được hỗ trợ và thay đổi đang âm thầm bỏ qua.

• Khi bạn gắn bộ chứa lưu trữ của mình bằng gcsfuse, nhân cầu chì lớp hạn chế quyền truy cập hệ thống tệp đối với người dùng đã gắn tệp hệ thống. Nếu bạn muốn cung cấp quyền truy cập cho người dùng khác, bạn có thể ghi đè hành vi này bằng tùy chọn mount allow_other cùng với cờ --uid và --gid. Tuy nhiên, hãy nhớ rằng điều này có thể có ý nghĩa bảo mật. Nhìn thấy đây cho tài liệu

• Nếu một người không muốn thực hiện chmod với quyền 777/666 hoặc sử dụng allow_other anh ấy có thể thử tự thêm mình vào nhóm cầu chì và thay đổi nhóm để hợp nhất trong thiết bị/dev/fuse. Tôi đã xem qua GitHub này bình luận vấn đề mà có vẻ công bằng. Mọi thứ hoạt động cục bộ với --privileged cờ được truyền cho docker run mặc dù thiết bị được sở hữu bởi gốc: gốc. Trong bình luận về vấn đề GitHub, người ta nói rằng họ thay đổi nhóm thành cầu chì trong thiết bị/dev/fuse. Họ phải thực hiện dưới quyền root và đó có thể là một giải pháp cho tất cả người dùng không muốn trải qua 777/ allow_other/ --uid,--gid, 666 hacks.