containers / podman

Podman: A tool for managing OCI containers and pods.
https://podman.io
Apache License 2.0
23.83k stars 2.42k forks source link

ADD/COPY in podman on windows does not set executable bit #15299

Open alisonatwork opened 2 years ago

alisonatwork commented 2 years ago

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind bug

Description

I am not exactly sure if this is a bug or a feature request, but if the goal for Podman on Windows is to maintain reasonable compatibility with Docker Desktop, this is something that will need to be addressed.

Because Windows doesn't have file permissions that work the same way as on UNIX, by default Docker on Windows copies files into the container with default permissions 0755, i.e. rwx for owner. Podman seems to instead supply 0666 permissions, i.e. rw for all. This means that if an executable (usually a shell script) is copied into the container, it will not run when the container is built with Podman, unless the container explicitly chmods the script. This is perhaps good practice, but it's not always done, especially thanks to the Docker default.

Steps to reproduce the issue:

  1. Create a small project like this:
$ uname
MINGW64_NT-10.0-22621
$ cat Dockerfile
FROM alpine
COPY hello.sh /tmp
RUN ls -l /tmp && /tmp/hello.sh
$ cat hello.sh
#!/bin/sh

echo "hello, world"
  1. Build project using Docker Desktop
$ docker build --no-cache .
Sending build context to Docker daemon  3.072kB
STEP 1/3: FROM alpine
STEP 2/3: COPY hello.sh /tmp
--> 7bda2aa2ea8
STEP 3/3: RUN ls -l /tmp && /tmp/hello.sh
total 4
-rwxr-xr-x    1 root     root            31 Aug 12 11:39 hello.sh
hello, world
COMMIT
--> b5df6c394d2
b5df6c394d2fc36e7620042ef9880b757a6a3c4de36182116ca5a189114e5615
Successfully built b5df6c394d2f
SECURITY WARNING: You are building a Docker image from Windows against a non-Windows Docker host. All files and directories added to build context will have '-rwxr-xr-x' permissions. It is recommended to double check and reset permissions for sensitive files and directories.

Use 'docker scan' to run Snyk tests against images to find vulnerabilities and learn how to fix them
  1. Build project using Podman for Windows
$ podman build --no-cache .
STEP 1/3: FROM alpine
STEP 2/3: COPY hello.sh /tmp
--> 56703059241
STEP 3/3: RUN ls -l /tmp && /tmp/hello.sh
/bin/sh: /tmp/hello.sh: Permission denied
total 4
-rw-rw-rw-    1 root     root            31 Aug 12 11:39 hello.sh
Error: error building at STEP "RUN ls -l /tmp && /tmp/hello.sh": error while running runtime: exit status 126

Describe the results you received:

This small project fails to build in Podman on Windows because copied files do not have the execute bit set.

Describe the results you expected:

I expect the execute bit to be set, so that Dockerfiles that work in Docker Desktop on Windows behave the same in Podman on Windows.

Additional information you deem important (e.g. issue happens only occasionally):

I can understand if it's not desirable to always set the execute bit on everything that gets copied from Windows. But perhaps there could be a setting that would allow the user to control what the default permissions should be when ADD or COPY is encountered, only on Windows. I think some users would prefer 0755, even if others still want 0666. (On UNIX-like operating systems, the permissions can just be maintained as-is.)

Output of podman version:

Client:       Podman Engine
Version:      4.1.1
API Version:  4.1.1
Go Version:   go1.16.15
Git Commit:   f73d8f8875c2be7cd2049094c29aff90b1150241
Built:        Wed Jun 15 21:17:12 2022
OS/Arch:      windows/amd64

Server:       Podman Engine
Version:      4.2.0-rc3
API Version:  4.2.0-rc3
Go Version:   go1.16.15
Built:        Sat Aug  6 04:18:20 2022
OS/Arch:      linux/amd64

Output of podman info:

host:
  arch: amd64
  buildahVersion: 1.27.0-dev
  cgroupControllers: []
  cgroupManager: cgroupfs
  cgroupVersion: v1
  conmon:
    package: conmon-2.1.3-1.fc35.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.3, commit: '
  cpuUtilization:
    idlePercent: 99.92
    systemPercent: 0.05
    userPercent: 0.03
  cpus: 8
  distribution:
    distribution: fedora
    variant: container
    version: "35"
  eventLogger: file
  hostname: REDACTED
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  kernel: 5.4.72-microsoft-standard-WSL2
  linkmode: dynamic
  logDriver: journald
  memFree: 7543496704
  memTotal: 8129556480
  networkBackend: netavark
  ociRuntime:
    name: crun
    package: crun-1.5-1.fc35.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 1.5
      commit: 54ebb8ca8bf7e6ddae2eb919f5b82d1d96863dea
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
  os: linux
  remoteSocket:
    exists: true
    path: /run/user/1000/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: true
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: false
  serviceIsRemote: true
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.1.12-2.fc35.x86_64
    version: |-
      slirp4netns version 1.1.12
      commit: 7a104a101aa3278a2152351a082a6df71f57c9a3
      libslirp: 4.6.1
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.5.3
  swapFree: 2147483648
  swapTotal: 2147483648
  uptime: 0h 43m 37.00s
plugins:
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  volume:
  - local
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - docker.io
  - quay.io
store:
  configFile: /home/user/.config/containers/storage.conf
  containerStore:
    number: 4
    paused: 0
    running: 0
    stopped: 4
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /home/user/.local/share/containers/storage
  graphRootAllocated: 269490393088
  graphRootUsed: 1958055936
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 13
  runRoot: /run/user/1000/containers
  volumePath: /home/user/.local/share/containers/storage/volumes
version:
  APIVersion: 4.2.0-rc3
  Built: 1659730700
  BuiltTime: Sat Aug  6 04:18:20 2022
  GitCommit: ""
  GoVersion: go1.16.15
  Os: linux
  OsArch: linux/amd64
  Version: 4.2.0-rc3

Package info (e.g. output of rpm -q podman or apt list podman):

N/A

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/main/troubleshooting.md)

Yes (latest version available from winget repo - 4.1.1)

Additional environment details (AWS, VirtualBox, physical, etc.):

Windows 11, version 22H2 build 22621.382

mheon commented 2 years ago

@n1hility PTAL

n1hility commented 2 years ago

FYI still on my radar, just haven't gotten to it yet.

github-actions[bot] commented 2 years ago

A friendly reminder that this issue had no activity for 30 days.

github-actions[bot] commented 2 years ago

A friendly reminder that this issue had no activity for 30 days.

Ev3rdown commented 1 year ago

Hello, I got there after troubleshooting an EACCES error during my container's build that only appeared with podman, turns out my script doesn't have the +x bit set when I use "COPY". Any update on this issue since the original post ? Is it intentionally kept this way ?

kevinshurtz commented 2 weeks ago

Hey team! I just wanted to mention that this is causing me some friction with the Ansible Builder project.

I'm a Windows user, which means I can't run Ansible Playbooks directly (without the WSL), so I'd really like to use Ansible Builder to create execution environments with Podman and run the resulting container images. This workflow means I don't have to jump between shells for different parts of the project, and building immutable images for executing playbooks would offer a lot of development and operational benefits.

I'm just starting to explore the Ansible Builder documentation, and right out of the gate, it doesn't work. Upon running ansible-builder build on a near-empty Ansible project, I get a "permission error" when it tries to build the Containerfile.

The issue is that the generated Containerfile copies various scripts from the host, which it assumes will be executable, and throws an error when it turns out they're not. This may not be an issue on Linux, and it may not be an issue for Docker, but for Podman on Windows, it means that other projects like Ansible Builder aren't usable without some awkward workarounds.

In this particular case, there's also a fair argument to be made that the COPY commands generated in the Containerfile by the Ansible Builder project should be generated with a --chmod flag setting to mitigate this issue. I'm happy to open an issue there too if that's the team's preference.

That said, setting the executable bit by default in Podman would alleviate this issue for me and complement the efforts other Red Hat-supported projects that implicitly depend on it.

Thank you so much, and please let me know if there is anything else I can share!