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

Volume mount readonly boolean value is not read correctly #18995

Closed
fangpenlin opened this issue Jun 26, 2023 · 0 comments · Fixed by #19015
Closed

Volume mount readonly boolean value is not read correctly #18995

fangpenlin opened this issue Jun 26, 2023 · 0 comments · Fixed by #19015
Labels
kind/bug Categorizes issue or PR as related to a bug. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. remote Problem is in podman-remote

Comments

@fangpenlin
Copy link
Contributor

Issue Description

Here's what the doc says about the volume mount readonly option:

   Options specific to volume:

      · ro, readonly: true or false (default).

      . U, chown: true or false (default). Change recursively the owner and group of the source volume based on the UID and GID of the container.

      · idmap: true or false (default).  If specified, create an idmapped mount to the target user namespace in the container.
      The idmap option supports a custom mapping that can be different than the user namespace used by the container.
      The mapping can be specified after the idmap option like: `idmap=uids=0-1-10#10-11-10;gids=0-100-10`.  For each triplet, the first value is the
      start of the backing file system IDs that are mapped to the second value on the host.  The length of this mapping is given in the third value.
      Multiple ranges are separated with #.  If the specified mapping is prepended with a '@' then the mapping is considered relative to the container
      user namespace. The host ID for the mapping is changed to account for the relative position of the container user in the container user namespace.

and the example

type=volume,source=vol1,destination=/path/in/container,ro=true

But if you run this:

podman run --mount type=volume,destination=/path/in/container,ro=false alpine touch /path/in/container/a

and you will get

touch: /path/in/container/a: Read-only file system

If you remove the ro or readonly option, it will become writable, like this

podman run --mount type=volume,destination=/path/in/container alpine touch /path/in/container/a

So it turned out that the document was not correct, or the implementation of volume option parsing is wrong. Boolean value should be parsed instead of just checking readonly option appears or not.

Steps to reproduce the issue

Run

podman run --mount type=volume,destination=/path/in/container,ro=false alpine touch /path/in/container/a

or

podman run --mount type=volume,destination=/path/in/container,readonly=false alpine touch /path/in/container/a

Describe the results you received

Read-only file system

Describe the results you expected

It should be writable if the readonly option is set to false.

podman info output

host:
  arch: amd64
  buildahVersion: 1.30.0
  cgroupControllers: []
  cgroupManager: cgroupfs
  cgroupVersion: v1
  conmon:
    package: conmon-2.1.7-2.fc37.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.7, commit: '
  cpuUtilization:
    idlePercent: 99.4
    systemPercent: 0.27
    userPercent: 0.33
  cpus: 32
  databaseBackend: boltdb
  distribution:
    distribution: fedora
    variant: container
    version: "37"
  eventLogger: journald
  hostname: MY-PC
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 524288
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 524288
      size: 65536
  kernel: 5.15.90.1-microsoft-standard-WSL2
  linkmode: dynamic
  logDriver: journald
  memFree: 342667264
  memTotal: 16720412672
  networkBackend: netavark
  ociRuntime:
    name: crun
    package: crun-1.8.5-1.fc37.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 1.8.5
      commit: b6f80f766c9a89eb7b1440c0a70ab287434b17ed
      rundir: /run/user/1000/crun
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +LIBKRUN +WASM:wasmedge +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.2.0-8.fc37.x86_64
    version: |-
      slirp4netns version 1.2.0
      commit: 656041d45cfca7a4176f6b7eed9e4fe6c11e8383
      libslirp: 4.7.0
      SLIRP_CONFIG_VERSION_MAX: 4
      libseccomp: 2.5.3
  swapFree: 4278091776
  swapTotal: 4294967296
  uptime: 35h 32m 55.00s (Approximately 1.46 days)
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  - ipvlan
  volume:
  - local
registries:
  localhost:7000:
    Blocked: false
    Insecure: true
    Location: 192.168.50.80:7000
    MirrorByDigestOnly: false
    Mirrors: null
    Prefix: localhost:7000
    PullFromMirror: ""
  search:
  - docker.io
store:
  configFile: /home/user/.config/containers/storage.conf
  containerStore:
    number: 435
    paused: 0
    running: 0
    stopped: 435
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /home/user/.local/share/containers/storage
  graphRootAllocated: 1081101176832
  graphRootUsed: 4428083200
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 99
  runRoot: /run/user/1000/containers
  transientStore: false
  volumePath: /home/user/.local/share/containers/storage/volumes
version:
  APIVersion: 4.5.0
  Built: 1681486976
  BuiltTime: Fri Apr 14 08:42:56 2023
  GitCommit: ""
  GoVersion: go1.19.7
  Os: linux
  OsArch: linux/amd64
  Version: 4.5.0


### Podman in a container

No

### Privileged Or Rootless

None

### Upstream Latest Release

No

### Additional environment details

Additional environment details

### Additional information

Additional information like issue happens only occasionally or issue happens with a particular architecture or on a particular setting
@fangpenlin fangpenlin added the kind/bug Categorizes issue or PR as related to a bug. label Jun 26, 2023
@github-actions github-actions bot added the remote Problem is in podman-remote label Jun 26, 2023
rhatdan added a commit to rhatdan/podman that referenced this issue Jun 27, 2023
There was a huge cut and paste of mount options which were not constent
in parsing tmpfs, bind and volume mounts.  Consolidated into a single
function to guarantee all parse the same.

Fixes: containers#18995

Signed-off-by: Daniel J Walsh <[email protected]>
ashley-cui pushed a commit to ashley-cui/podman that referenced this issue Jul 13, 2023
There was a huge cut and paste of mount options which were not constent
in parsing tmpfs, bind and volume mounts.  Consolidated into a single
function to guarantee all parse the same.

Fixes: containers#18995

Signed-off-by: Daniel J Walsh <[email protected]>
@github-actions github-actions bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Sep 26, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 26, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
kind/bug Categorizes issue or PR as related to a bug. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. remote Problem is in podman-remote
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant