首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >问答首页 >未能打开/dev/fuse:权限被拒绝

未能打开/dev/fuse:权限被拒绝
EN

Server Fault用户
提问于 2022-05-13 11:42:42
回答 1查看 1.1K关注 0票数 0

我以普通的非根用户的身份在容器中运行以下命令

代码语言:javascript
运行
复制
gcsfuse --foreground --debug_fuse --debug_fs --debug_gcs --debug_http my-bucket /data

当我用--priviliged启动容器时,它在本地工作,这很好。

但在云运行(使用第二代预览执行环境时),同样的情况并不适用。我得到以下错误:

代码语言:javascript
运行
复制
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中这样创建我的用户

代码语言:javascript
运行
复制
RUN useradd -lmU joe\
  && mkdir -p /data \
  && chown -R joe:joe /data
USER joe

我应该以使用文件系统的用户而不是根用户的身份运行gcs引信的医生说,但它不起作用。知道我做错什么了吗?

EN

回答 1

Server Fault用户

发布于 2022-05-31 11:36:27

为寻求这个问题的答案的社区:

根据这个回答,在gcsfuse.sh中添加-file-mode=777-dir-mode=777和gcsfuse命令,以便在GCS桶的挂载目录中启用读/写应该是一种选择,但由于科伯特确认出于安全原因,它不起作用。我进一步挖掘,我发现这些非常有用的信息:

  • 默认情况下,gcs引信文件系统中的所有inode都显示为gcs引信进程本身的UID和GID所拥有,即安装文件系统的用户。644和755是gcs引信文件系统中所有文件和目录inode的默认权限。不支持更改inode模式(使用chmod(2)或类似的模式),并且忽略了更改。
  • 使用gcs引信挂载存储桶时,fuse内核层将文件系统访问限制为安装文件系统的用户。如果您希望提供对其他用户的访问,可以使用allow_other挂载选项以及--uid和-gid标志覆盖此行为。但是,请记住,这可能会对安全产生影响。有关文档,请参见这里
  • 如果一个人不想使用777/ 666权限执行chmod或使用allow_other,他可以尝试将自己添加到fuse组中,并将该组更改为/dev/fuse设备中的fuse。我偶然发现了GitHub 发行评论,这似乎很公平。即使设备是由root:root拥有的,传递给码头运行的特权标志也可以在本地工作。在GitHub发布的评论中,据说他们将组更改为在/dev/fuse设备中进行融合。它们必须在根下执行,这可能是所有不想通过777/ allow_other/ -uid、--gid、666个黑客的用户的解决方案。
票数 1
EN
页面原文内容由Server Fault提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://serverfault.com/questions/1100860

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档