Podman pull not respecting current umask

[hartmafk]

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

/kind bug

Description

podman pull is not respecting current umask when using pull with root= and additionalimagestores

Steps to reproduce the issue:

1. Set umask via umask 002

2. Issue container pull into empty imagestore, e.g., /opt/container podman --root=podman --root=/opt/container/ pull docker.io/gcc:11.2

3. Observe current permissions

Describe the results you received:

ls -la .
total 40
drwxr-xr-x  9 podman podman 4096 Apr 26 15:07 .
drwxr-xr-x 15 root   root   4096 Apr 25 12:23 ..
drwx------  2 podman podman 4096 Apr 26 15:07 libpod
drwx------  2 podman podman 4096 Apr 26 15:07 mounts
drwx------ 12 podman podman 4096 Apr 26 15:07 overlay
drwx------  2 podman podman 4096 Apr 26 15:07 overlay-containers
drwx------  3 podman podman 4096 Apr 26 15:07 overlay-images
drwx------  2 podman podman 4096 Apr 26 15:07 overlay-layers
-rw-r--r--  1 podman podman   64 Apr 26 15:07 storage.lock
drwx------  2 podman podman 4096 Apr 26 15:07 tmp
-rw-r--r--  1 podman podman    0 Apr 26 15:07 userns.lock

Describe the results you expected:

I expected the files to be read/executable by all users as defined in umask.

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

Output of podman version:

podman version
Version:      3.4.4
API Version:  3.4.4
Go Version:   go1.17.3
Built:        Thu Jan  1 00:00:00 1970
OS/Arch:      linux/s390x

Output of podman info --debug:

podman info --debug
host:
  arch: amd64
  buildahVersion: 1.23.1
  cgroupControllers:
  - memory
  - pids
  cgroupManager: cgroupfs
  cgroupVersion: v2
  conmon:
    package: 'conmon: /usr/bin/conmon'
    path: /usr/bin/conmon
    version: 'conmon version 2.0.25, commit: unknown'
  cpus: 8
  distribution:
    codename: jammy
    distribution: ubuntu
    version: "22.04"
  eventLogger: file
  hostname: lnxzvmd1
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1019
      size: 1
    - container_id: 1
      host_id: 1410720
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1019
      size: 1
    - container_id: 1
      host_id: 1410720
      size: 65536
  kernel: 5.15.0-25-generic
  linkmode: dynamic
  logDriver: journald
  memFree: 14074150912
  memTotal: 16645828608
  ociRuntime:
    name: runc
    package: 'runc: /usr/sbin/runc'
    path: /usr/sbin/runc
    version: |-
      runc version 1.1.0-0ubuntu1
      spec: 1.0.2-dev
      go: go1.17.3
      libseccomp: 2.5.3
  os: linux
  remoteSocket:
    path: /tmp/podman-run-1019/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: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: 'slirp4netns: /usr/bin/slirp4netns'
    version: |-
      slirp4netns version 1.0.1
      commit: 6a7b16babc95b6a3056b33fb45b74a6f62262dd4
      libslirp: 4.6.1
  swapFree: 0
  swapTotal: 0
  uptime: 27h 2m 23.38s (Approximately 1.12 days)
plugins:
  log:
  - k8s-file
  - none
  - journald
  network:
  - bridge
  - macvlan
  volume:
  - local
registries: {}
store:
  configFile: /home/podman/.config/containers/storage.conf
  containerStore:
    number: 0
    paused: 0
    running: 0
    stopped: 0
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /home/podman/.local/share/containers/storage
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 0
  runRoot: /tmp/podman-run-1019/containers
  volumePath: /home/podman/.local/share/containers/storage/volumes
version:
  APIVersion: 3.4.4
  Built: 0
  BuiltTime: Thu Jan  1 00:00:00 1970
  GitCommit: ""
  GoVersion: go1.17.3
  OsArch: linux/s390x
  Version: 3.4.4

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

podman/jammy,now 3.4.4+ds1-1ubuntu1 s390x [installed]

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)

No, did not verify latest version.
Yes, did read Podman Troubleshooting Guide.

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

I have run into this issue trying to implement the excellent guidance from this blog post: https://www.redhat.com/sysadmin/image-stores-podman

[Luap99]

This is not how umask works. umask removes the permission bits from the file. If the file is already created with less permissions that is fine.

The blog mentions that you have to manually chown the files:
sudo chmod -R a+rx /var/lib/mycontainers

I don't think it is a good idea to make images world readable by other as default. @vrothberg @rhatdan WDYT?

[hartmafk]

None of the files or folders were in existance at the time of the pull, it was a completely fresh folder.

I have tried ACLs with default permissions too but had the same issue, the newly created files and folders did not obey the default ACL permissions too.

The idea of this additional immage store is to eliminate the requirement that every user on the syae system needs to have a duplicate of all images required for development and that these images can be updated and refreshed in a central location for all users.

I agree that it's not best practice to have all images readable by everybody by default but so far there seems no way to do that when you want to.

[rhatdan]

Look at the force_mask field in storage.conf.

# ForceMask specifies the permissions mask that is used for new files and
# directories.
#
# The values "shared" and "private" are accepted.
# Octal permission masks are also accepted.
#
#  "": No value specified.
#     All files/directories, get set with the permissions identified within the
#     image.
#  "private": it is equivalent to 0700.
#     All files/directories get set with 0700 permissions.  The owner has rwx
#     access to the files. No other users on the system can access the files.
#     This setting could be used with networked based homedirs.
#  "shared": it is equivalent to 0755.
#     The owner has rwx access to the files and everyone else can read, access
#     and execute them. This setting is useful for sharing containers storage
#     with other users.  For instance have a storage owned by root but shared
#     to rootless users as an additional store.
#     NOTE:  All files within the image are made readable and executable by any
#     user on the system. Even /etc/shadow within your image is now readable by
#     any user.
#
#   OCTAL: Users can experiment with other OCTAL Permissions.
#
#  Note: The force_mask Flag is an experimental feature, it could change in the
#  future.  When "force_mask" is set the original permission mask is stored in
#  the "user.containers.override_stat" xattr and the "mount_program" option must
#  be specified. Mount programs like "/usr/bin/fuse-overlayfs" present the
#  extended attribute permissions to processes within containers rather then the
#  "force_mask"  permissions.
#
# force_mask = ""

[hartmafk]

I cleaned our the folder, repulled the container, unfortunately with no change.

This doesn't seem not change the container image management .
podman pull will still ignore the user's set umask or any existing ACL, making a chmod necessary after every pull.

[legaul-cisco]

+1, this doesn't seem to help, and the reported issue seems like a bug to me.