Volumes always owned by root

[fnkr]

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

/kind bug

Description

Volumes are always owned by root instead of inheriting owner and group from the host.

Steps to reproduce the issue:

1. Run podman run --rm -v "$HOME:$HOME" alpine ls -l "$HOME/.."

total 4
drwx------   35 root     root          4096 Apr 11 07:55 fnkr

2. Run podman run --rm -v "$HOME:$HOME" --user "$(id -u):$(id -g)" alpine ls -l "$(dirname $HOME)"

total 4
drwx------   35 root     root          4096 Apr 11 07:55 fnkr

Describe the results you received:

The mount is owned by root.

Describe the results you expected:

The mount should be owned by the current user in both cases. (At least this is what Docker does.)

➜ docker run --rm -v "$HOME:$HOME" alpine ls -l "$HOME/.."
total 4
drwx------   35 1001     1001          4096 Apr 11 08:01 fnkr

➜ docker run --rm -v "$HOME:$HOME" --user "$(id -u):$(id -g)" alpine ls -l "$(dirname $HOME)"
total 4
drwx------   35 1001     1001          4096 Apr 11 08:01 fnkr

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

100% reproducible. Probably related to #2643 and #2634.

Output of podman version:

➜ podman version                                                                             
Version:            1.2.0
RemoteAPI Version:  1
Go Version:         go1.11.5
OS/Arch:            linux/amd64

Output of podman info --debug:

debug:
  compiler: gc
  git commit: ""
  go version: go1.11.5
  podman version: 1.2.0
host:
  BuildahVersion: 1.7.2
  Conmon:
    package: podman-1.2.0-2.git3bd528e.fc29.x86_64
    path: /usr/libexec/podman/conmon
    version: 'conmon version 1.12.0-dev, commit: d88bb0e63cb70f9787a8e410716924f380af361f'
  Distribution:
    distribution: fedora
    version: "29"
  MemFree: 10356088832
  MemTotal: 25145073664
  OCIRuntime:
    package: runc-1.0.0-68.dev.git6635b4f.fc29.x86_64
    path: /usr/bin/runc
    version: |-
      runc version 1.0.0-rc6+dev
      commit: ef9132178ccc3d2775d4fb51f1e431f30cac1398-dirty
      spec: 1.0.1-dev
  SwapFree: 0
  SwapTotal: 0
  arch: amd64
  cpus: 8
  hostname: ping
  kernel: 5.0.6-200.fc29.x86_64
  os: linux
  rootless: true
  uptime: 1h 54m 36.7s (Approximately 0.04 days)
insecure registries:
  registries: []
registries:
  registries:
  - docker.io
  - registry.fedoraproject.org
  - quay.io
  - registry.access.redhat.com
  - registry.centos.org
store:
  ConfigFile: /home/fnkr/.config/containers/storage.conf
  ContainerStore:
    number: 1
  GraphDriverName: overlay
  GraphOptions:
  - overlay.mount_program=/usr/bin/fuse-overlayfs
  GraphRoot: /home/fnkr/.local/share/containers/storage
  GraphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  ImageStore:
    number: 26
  RunRoot: /run/user/1001
  VolumePath: /home/fnkr/.local/share/containers/storage/volumes

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

I'm using Fedora Workstation 29.

[rhatdan]

Podman by default in rootless mode makes the UID of the user running the command ROOT inside of the container. That means that when you look at the UID of the running process it will be 0, even though the process is really running as your UID. Also any files with your UID as owner or group will be seen as UID==0 while in the container. Any file actually owned by a UID==0 will be seen as -1.

So this is not a bug.
What are you hoping to do in the container?

[fnkr]

Hi @rhatdan, thanks for your response. Is there any way to use --user together with volumes? In my use case the name, group, UID, GID and home dir of the user are relevant and I need to access certain files from host and container processes. This is a simplified example of what I'm doing (works with Docker):

--user=$UID --volume="$HOME/build/passwd:/etc/passwd:ro" --volume="$HOME/build:$HOME/build" --workdir="$HOME/build"

[rhatdan]

If you eliminate the --user=$UID it should work for you, but you will think you are running as root inside of the container. Another option is to use the User Namespace differently.

I am going to guess that your UID == 1000, Current
And you have a line like this in the /etc/subuid file.
fnkr:100000:65536
If you ran podman with the following commands
$ podman run --uidmap 0:100000:1000 --uidmap 1000:1000:1 --uidmap 1001:101000:64536 ...
Then you will get the environment you envision.
You will have to play with the UID Ranges above to get this correct.

@giuseppe I wonder if we should make this an option for podman,
podman --uidmap user, which would do the above automatically.

[fnkr]

➜ podman run --uidmap 0:100000:1000 --uidmap 1000:1000:1 --uidmap 1001:101000:64536 alpne ls 
Error: error creating libpod runtime: there might not be enough IDs available in the namespace (requested 100000:100000 for /home/fnkr/.local/share/containers/storage/overlay/l): chown /home/fnkr/.local/share/containers/storage/overlay/l: invalid argument

I changed the command slightly to get it working, but now files from the volume are owned by nobody:

➜ podman run --rm -v="$PWD:$PWD" -w="$PWD" --uidmap=0:10000:$((UID)) --uidmap=$UID:$UID:1 --uidmap=$((UID+1)):$((UID+10001)):$((55536-UID)) alpine ls -l -n
total 0
-rw-r--r--    1 65534    65534            0 Apr 12 17:47 test

➜ ls -l -n       
total 0
-rw-r--r--. 1 1001 1001 0 Apr 12 17:47 test

[rhatdan]

I like it, I would love to make this easier for non expert users.
Seems like users are running non rootl containers, where they expect their UID==UID in the container and others expect their UID == 0 inside the container. The desktop team has built toolbox which is a wrapper around podman but does the UID==UID mapping.

[mheon]

podman run --match-uid maybe?

[rhatdan]

I would want something to indicate this is usernamespace --userns-map-uid

[giuseppe]

we could do that, it should be pretty easy. We need to provide a preconfigured mapping for the namespace. We also need --user to be configured though

[mheon]

We could default to the logged-in user's UID

[rhatdan]

@giuseppe Why would we need --user? I still am fine with them being root when the container starts and then remapping to their user.

[rhatdan]

@mheon I don't think we should change the default. If we had a flag that changed the default then you could toggle the flag via an environment variable.

[giuseppe]

We need user for the effective setresuid in the oci runtime, that needs to happen after the second mapping is in place.

[fnkr]

Hi,

I couldn't figure out how to fix this yet. If I use --uidmap the UID/GID of volumes is always 65534.

➜ podman run --rm -v="$PWD:$PWD" -w="$PWD" --uidmap=0:10000:$((UID)) --uidmap=$UID:$UID:1 --uidmap=$((UID+1)):$((UID+10001)):$((55536-UID)) alpine ls -l -n
total 0
-rw-r--r--    1 65534    65534            0 Apr 12 17:47 test

➜ ls -l -n       
total 0
-rw-r--r--. 1 1001 1001 0 Apr 12 17:47 test