-
Notifications
You must be signed in to change notification settings - Fork 18.7k
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
Proposal: Handling of permission bits for image context created via Windows #11047
Comments
IANTM, but this seems to be the best compromise from what I can tell. So +1 from me. |
First of all, thanks for looking into this. In general I can see this as a reasonable compromise (but of course hope something better can be invented in future). I'll add a couple of ideas / concerns;
|
@thaJeztah that is also another option. I just wanted to make sure if it is okay to drop the x bit and leave If we can just abandon the requirement of preserving the 'x' bit when deployed from windows, it's fine with me either. I guess developers working on windows machines deploying things to Linux servers already don't use much of +x bit. 😃 (correct me if you think this is a wrong assumption). As you said, they won't be sruprised. You are also right about remote git builds. If the user cares about git repo, they can use that. We don't need to find out if we're on a git repo then check index for file metadata. |
In my experience with Windows filesystems on Unix systems, they're usually
"everything is +x". Why not take that approach here instead? Having +x
where you didn't need it is usually harmless (and only dangerous if you're
especially careless), and not having +x (and thus having to set it after
the COPY via "chmod") runs into AUFS issues, so that seems like a cleaner
compromise from the end-user perspective IMO.
|
@tianon I wasn't aware of the AUFS situation tbh. That's what I initially suggested but security problems are my biggest concern. We might assume people know what they're doing by adding a warning message and just make everything We mostly assume user knows what they COPY/ADD to container, so the only +x'ed stuff are going to be those files. And if it happens so that somebody gains shell access to inside container, they can "chmod +x" or replace system binaries anyway. I'm mostly convinced to follow "everything +x" at this point. |
FWIW, I agree with +x'ing everything. Not ideal but really the only choice we have. Making people explicitly do a "chmod +x" themselves will almost guarantee people avoid the Windows CLI, which would be bad. |
Be consistent with `docker build`, which marks the files in the context tarball as executable. See also moby/moby#11047. Fixes docker#937.
The build context is tarred up on the client and then sent to the Docker daemon. However Windows permissions don't match the Unix ones. Therefore we have to mark all files as executable when creating a build context on Windows, like `docker build` already does: moby/moby#11047. Signed-off-by: Sebastian Schwarz <seschwar@gmail.com>
The build context is tarred up on the client and then sent to the Docker daemon. However Windows permissions don't match the Unix ones. Therefore we have to mark all files as executable when creating a build context on Windows, like `docker build` already does: moby/moby#11047. Signed-off-by: Sebastian Schwarz <seschwar@gmail.com>
The build context is tarred up on the client and then sent to the Docker daemon. However Windows permissions don't match the Unix ones. Therefore we have to mark all files as executable when creating a build context on Windows, like `docker build` already does: moby/moby#11047. Signed-off-by: Sebastian Schwarz <seschwar@gmail.com>
Problem
Converting Windows file attributes + ACLs to 9-bit UNIX permissions when
docker images are built from windows CLI. Concept of 'execute' doesn't
match 1:1 on Windows vs POSIX.
Scenario
docker build .
Problem steps:
setup.sh
script (chmod +x
ed)x
bit on windows, so duringgit clone
we lost that bit-rw-rw-rw-
permissions.RUN ./setup.sh
orENTRYPOINT ./setup.sh
it will faildue to a vague "permission denied" error because script was not
chmod +x
ed.+x
bit was missing.RUN chmod +x setup.sh
as a dockerfile instruction if they'rebuilding from Windows.
Root cause 1: No 'x' (execute) bit on Windows
+x
ed file from ftp/git/unzip/samba, we lose thatunix bit on windows, because it's not the same thing.
Quoting from SAMBA book:
Root cause 2: Go Windows Problems
Golang's os.Stat implementation is very poor:
Windows but an ACL setting –found out through a separate syscall, not implemented in golang)
-rw-rw-rw-
for all files on Windows and that's the permission what files copied to a docker build context gets by default.-rw-rw-rw-
permissions by default, that's the state we're in now).We are hoping to address problems in golang in the long term. (fingers crossed)
Solution
-???------
r
from group/others, this might break multi-user docker images.+x
to all files packaged from windows. 💥+x
on all files and can support executing./binary
or./script.sh
from shell.+x
ed files as input. I haven't really heard of anything like that,must be a really rare case. Even so user can have
RUN chmod -x
to remove that bit manuallyWARNING: Permission bits on files added to image might not be correctly set.
🆕Proposed Fix
We modify the perm bits of the tar header created via
tar.FileInfoHeader
with a simple platform-specific helper method. (see code)
We are also going to change the expected permission string
on the integration-cli test cases when executed on windows.
Result
We will end up with a docker image in which all files copied from
Windows filesystem have (1) grp/others bits cleared (2)
+x
addedregardless of it should have
+x
because it does no harm.Behavior on Linux/Mac CLIs are unchanged.
I really appreciate your input on this. That's the only thing left prevents us from getting green on Windows client CI.
cc: @ewindisch @crosbymichael @cpuguy83 @tianon @tiborvass @jfrazelle @icecrime @johngossman @sachin-jayant-joshi @jhowardmsft
The text was updated successfully, but these errors were encountered: