☰

gcsfuse 无法打开 /dev/fuse：权限被拒绝

tag-icon • tag-icon google-cloud-platform gcsfuse
gcsfuse 无法打开 /dev/fuse：权限被拒绝

我以普通非 root 用户身份在容器内运行以下命令

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

并且有效本地当我启动容器时，--priviliged一切就都好了。

但在 Cloud Run 上，同样的方法不起作用（使用第二代预览执行环境时）。我收到以下错误：

2022-05-13 12:08:41.547 CEST gcs: 2022/05/13 10:08:41.546642 Req 0x1: -> ListObjects("") (46.897367ms): OK
2022-05-13 12:08:41.551 CEST /usr/bin/fusermount: failed to open /dev/fuse: Permission denied
2022-05-13 12:08:41.551 CEST mountWithArgs: mountWithConn: Mount: mount: running /usr/bin/fusermount: exit status 1

所有其他调试日志行、HTTP、GCS 等都显示一切正常。

我在我的中创建这样的用户Dockerfile

RUN useradd -lmU joe\
  && mkdir -p /data \
  && chown -R joe:joe /data
USER joe

这文档说我应该以使用文件系统的用户身份运行 gcsfuse，而不是以 root 身份运行，但不起作用。知道我做错了什么吗？

答案1

对于寻求此问题答案的社区：

根据此回答在 gcsfuse.sh 中添加 -file-mode=777 -dir-mode=777 和 gcsfuse 命令以在 GCS bucket 的挂载目录中启用读/写应该是一个选项，但是由于科汉伊·罗伯特确认出于安全原因，它无法达到目的。我进一步挖掘，发现了以下非常有用的信息：

  • 默认情况下，gcsfuse 文件系统中的所有 inode 都显示为由 gcsfuse 进程本身的 UID 和 GID 所拥有，即挂载文件系统的用户。644 和 755 是 gcsfuse 文件系统中所有文件和目录 inode 的默认权限。不支持更改 inode 模式（使用 chmod(2) 或类似方法），更改将被默默忽略。

  • 当您使用 gcsfuse 挂载存储桶时，fuse 内核层会将文件系统访问权限限制为挂载文件系统的用户。如果您想向其他用户提供访问权限，可以使用 allow_other 挂载选项以及 --uid 和 --gid 标志覆盖此行为。但是，请记住，这可能会带来安全隐患。请参阅这里用于文档

  • 如果某人不想使用 777/666 权限执行 chmod 或使用 allow_other，他可以尝试将自己添加到 fuse 组，并将该组更改为 /dev/fuse 设备中的 fuse。我偶然发现了这个 GitHub 问题评论这似乎很公平。即使设备归 root:root 所有，只要将 --privileged 标志传递给 docker run，事情就可以在本地运行。在 GitHub 问题评论中，据说他们将 /dev/fuse 设备中的组更改为 fuse。然后他们必须在 root 下执行，这可能是所有不想经历 777/allow_other/--uid,--gid,666 黑客攻击的用户的解决方案。

相关内容