Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update README.md - compose中指定user,附加简要说明 #102

Merged
merged 2 commits into from
May 8, 2024

Conversation

ky0utarou
Copy link
Contributor

@amtoaer
Copy link
Owner

amtoaer commented May 8, 2024

我现在对 user 会影响权限这个事情还抱有一定怀疑,因为正常来说文件权限是标准库设置的,设置 user 只会影响文件所有者才对。等后面我写个最小实例验证一下。
目前可以暂时先将这里的表述修改为”项目下载的文件所有者会与该处设置的 user 保持一致,不设置默认为 root“吗?
(以及可以在中英文之间加个空格 XD)

@ky0utarou
Copy link
Contributor Author

目前可以暂时先将这里的表述修改为”项目下载的文件所有者会与该处设置的 user 保持一致,不设置默认为 root“吗?
(以及可以在中英文之间加个空格 XD)

当然

因为正常来说文件权限是标准库设置的

我理解的你的意思是,标准库在创建poster.jpg的副本的时候,会把owner和permission原样复制。那按理说不管docker这边是什么用户,最终拿到的两个图片文件也应该是完全一样的。

@amtoaer
Copy link
Owner

amtoaer commented May 8, 2024

不,我描述的是整个下载过程的文件权限。如果 docker 以 x 用户运行,那么正常情况下:

  1. 新文件夹的 owner 是 x,权限 755
  2. 文件夹里下载的文件 owner 是 x,权限 644
  3. 文件里被 copy 出的 fanart owner 是 x,权限 644

如果用户是 root,那么正常只会影响到 owner 而不会影响到权限。但在你的 issue 截图中,下载的文件权限是 777,而 copy 结果的权限是 000。

如果这个是程序本身的行为,那说明使用 root 用户运行不仅影响到了 owner,还对文件权限产生了影响,这是不符合预期的。也就是我说的那个需要”验证“的问题。

至于你提到的这个是另外的场景。在我的认知里 copy 结果的 owner 会与程序执行时使用的 user 保持一致,并不会 copy 原文件的 owner。

@amtoaer amtoaer merged commit 8fee6fb into amtoaer:main May 8, 2024
1 check passed
amtoaer added a commit that referenced this pull request May 8, 2024
@ky0utarou
Copy link
Contributor Author

明白了👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants