-
Notifications
You must be signed in to change notification settings - Fork 778
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
umask 0077 breaks build-using-dockerfile with USER statement #1305
Comments
@giuseppe any thoughts? |
I recently fixed an issue in fuse-overlayfs not honoring umask. It is released as part of fuse-overlayfs 0.3: What version of fuse-overlayfs are you using? |
@giuseppe wrote:
I'd agree if that was manually created directory, but in this case -> I just inherited from |
I think we should make sure that the / of the image is searchable. 0755. If that is what the issue is? |
I am still not sure we should override the umask if it is set. If that is what the user expects, we are going to silently override it. I think we should just add a warning when |
Is this just leaking through to containers/storage? IE when it writes the image / ends up with two tight of permissions. I think we could eaisly override the permissions on /. |
we can simply solve it as:
but I am still not convinced we should silently do it. Perhaps we should just fail the build as having a |
This would require a definition of "expected umask value". I have (intentionally) 0077 for years on my box, but users can have any value there (default on Fedora is 0022 afaik). |
I think the only "expected umask value" should be 0. Anything else modifies how the image looks like, so we need to either error out, or force it to 0 and throw a warning |
|
an umask different than 0 breaks the reproducibility of the images, so force its value to 0. Closes: containers#1305 Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Proposed fix: #1325 I'll probably need to do the same thing for Podman |
an umask different than 0 breaks the reproducibility of the images, so force its value to 0. Closes: containers#1305 Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
an umask different than 0 breaks the reproducibility of the images, so force its value to 0. Closes: containers#1305 Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
an umask different than 0 breaks the reproducibility of the images, so force its value to 0. Closes: containers#1305 Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
an umask more restrictive can break some images. Closes: containers#1305 Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
BUG REPORT INFORMATION
Description
Ideally, buildah should make sure that the created
/
directory is created a standard way (say chmod 666 per filesystem.rpm content), or if it at least warned properly.Describe the results you received:
buildah bud
ends with strange permission error with umask 0077 afterUSER
command/statement.Describe the results you expected:
buildah bud
either works under those contitions.Output of
rpm -q buildah
orapt list buildah
:Output of
buildah version
:Output of
cat /etc/*release
:Output of
cat /etc/containers/storage.conf
:The text was updated successfully, but these errors were encountered: