VOLUME are mounted as noexec

[ensc]

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

/kind bug

Description

VOLUME in Dockerfile are mounted as noexec. This is unexpected, breaks existing systems. and derives from original docker (moby-engine-18.06.3) .

E.g.

FROM alpine:latest

VOLUME /var/tmp

RUN \
    printf "#! /bin/sh\ntrue" > /xtest

ENTRYPOINT ["/bin/sh", "-c", "install -m 0755 /xtest /var/tmp/xtest && /var/tmp/xtest"]

causes

$ podman run 819b47518da77b8f38430ecf9662924042a84de96377145893ca7e1988f222b1
/bin/sh: /var/tmp/xtest: Permission denied

while docker works fine

# docker run 3131c893800b
#

cat /proc/mounts within the container shows, that noexec mount flags are set for the /var/tmp bind mount.

Steps to reproduce the issue:

1. build a pod with VOLUME

Describe the results you received:

Volume is mounted without noexec flags

Describe the results you expected:

Volume is mounted with noexec flag.

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

*** podman inspect output ***

        "Config": {
            "Volumes": {
                "/var/tmp": {}
            }

Output of podman version:

$ podman version
Version:            1.6.1
RemoteAPI Version:  1
Go Version:         go1.12.9
OS/Arch:            linux/amd64

Output of podman info --debug:

debug:
  compiler: gc
  git commit: ""
  go version: go1.12.9
  podman version: 1.6.1
host:
  BuildahVersion: 1.11.2
  CgroupVersion: v1
  Conmon:
    package: conmon-2.0.1-1.fc30.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.1, commit: 4346fbe0b2634b05857973bdf663598081240374'
  Distribution:
    distribution: fedora
    version: "30"
  MemFree: 17307926528
  MemTotal: 33257033728
  OCIRuntime:
    package: runc-1.0.0-93.dev.gitb9b6cc6.fc30.x86_64
    path: /usr/bin/runc
    version: |-
      runc version 1.0.0-rc8+dev
      commit: e3b4c1108f7d1bf0d09ab612ea09927d9b59b4e3
      spec: 1.0.1-dev
  SwapFree: 4294963200
  SwapTotal: 4294963200
  arch: amd64
  cpus: 8
  eventlogger: journald
  hostname: ensc-virt.intern.sigma-chemnitz.de
  kernel: 5.2.18-200.fc30.x86_64
  os: linux
  rootless: true
  slirp4netns:
    Executable: /usr/bin/slirp4netns
    Package: slirp4netns-0.4.0-4.git19d199a.fc30.x86_64
    Version: |-
      slirp4netns version 0.4.0-beta.2
      commit: 19d199a6ca424fcf9516320a327cedad85cf4dfb
  uptime: 22h 10m 26.75s (Approximately 0.92 days)
registries:
  blocked: null
  insecure: null
  search:
  - docker.io
  - registry.fedoraproject.org
  - quay.io
  - registry.access.redhat.com
  - registry.centos.org
store:
  ConfigFile: /home/ensc/.config/containers/storage.conf
  ContainerStore:
    number: 9
  GraphDriverName: vfs
  GraphOptions: {}
  GraphRoot: /.local/home/ensc/.local/share/containers/storage
  GraphStatus: {}
  ImageStore:
    number: 33
  RunRoot: /run/user/505
  VolumePath: /.local/home/ensc/.local/share/containers/storage/volumes

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

podman-1.6.1-2.fc30.x86_64

[mheon]

Podman flags: rw,nosuid,nodev,noexec,relatime,seclabel
Docker flags: rw,relatime,seclabel

@rhatdan I'm inclined to leave the defaults for volumes we explicitly specify (-v and --mount) the same, but there's no way to adjust mount options for image volumes. Do we want to mirror Docker and strip everything, or just get rid of noexec?

[rhatdan]

Strip noexec.
The nodev we have added for images to /usr/share/containers/storage.conf by default. And nodev is just good to have for a security purposes. We don't want containers trusted random devices. Same argument could be made for nosuid.

I think noexec is the most overrated security mechanism for mount points, since it easy to bypass by using scripting languages like bash, python, perl, ruby, awk ...

[nicholasbishop]

Is there any workaround for this bug until my distro (Fedora) includes the fix?

[mheon]

You can create a volume and mount it over the path for the image volume, making sure to specify exec in the mount options so it's not mounted noexec.

We're in the process of cutting a new release, so a version of Podman with this fix will be available soon.

[nicholasbishop]

Just an FYI, I tried out a recent build of podman and while volumes specified with VOLUME are now mounted exec, volumes mounted with podman run --volume are still noexec. Not sure if that's expected behavior or not.

[mheon]

That's the default, but it can be changed by adding 'exec' to volume options.

…

On Thu, Nov 14, 2019, 00:46 Nicholas Bishop ***@***.***> wrote: Just an FYI, I tried out a recent build of podman and while volumes specified with VOLUME are now mounted exec, volumes mounted with podman run --volume are still noexec. Not sure if that's expected behavior or not. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#4318>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3AOCAE63RVC5AJVPX3RKDQTTQ2HANCNFSM4JDOR2CQ> .

[rhatdan]

Does that default match Docker?

[nicholasbishop]

No, Docker defaults to exec.

[rhatdan]

Ok I think we should match docker.

[rhatdan]

#4557 documents the defaults.

[klaus4040]

Maybe my brain shorts out after days getting into podman, but in podman 1.9.1 I think there is something wrong with image volumes and default options. The image defines a volume and podman finds it
DEBU[0000] Adding image volume at /var/atlassian/application-data/bitbucket
and i bind a volume of my own to it
-v bbvolume:/var/atlassian/application-data/bitbucket
yet in the end the defaults are ignored and noexec is used.
"Binds": [ "bbvolume:/var/atlassian/application-data/bitbucket:rw,rprivate,noexec,nosuid,nodev,rbind" ],
If I find time tomorrow to set up an IDE I can walk through the code easier than here directly in the source files ... setting exec manually works

[mheon]

I think that's fully expected - the image volume is overridden by your volume mount, and your named volume defaults to noexec. Right now, only image volumes default to exec. There has been significant talk about this, though, and I think my resistance to having the default be exec is crumbling.

[klaus4040]

k thanks, the container instructions by atlassian at docker.io with docker in mind don't tell to use the exec option, yet without the container doesn't start properly, so there is an inconsistency with docker then (propably, haven't checked).

[joelddiaz]

Ok I think we should match docker.

Quoting @rhatdan above. So is the intention to match Docker behavior regarding default mount flags? Because the Podman docs specifically state that you will get 'noexec' by default (differing from Docker).

[mheon]

I don't want to promise we will match completely; the utility of noexec is questionable and we may remove it, but I see definite value in nodev and nosuid and I don't think we'll be dropping those.

We presently also include noexec but I think we'll be dropping it by default (probably in v2.0)

[rhatdan]

I agree with removing noexec, keeping nosuid and nodev makes sense.

[mheon]

#6280 flips the default to off for named volumes.

[kallisti5]

oh wow.. this one was obnoxious to track down and not super obvious. All of our CI started breaking.

Pretty much compiling anything within a named volume requires exec (autoconf does a bunch of gcc compiler checks which execute test binaries)