Unable to expose rclone mount to host when using rootless

[andreluisos]

/kind bug

Description

Can't mount/expose mount when using rootless. Also, can't access the port.

Steps to reproduce the issue:

1. podman pull rclone/rclone:latest

2. mkdir -p ~/data/mount

podman run --rm \
--privileged \
--volume ~/rclone:/config/rclone \
--volume ~/data/mount:/data:shared \
--user 1000:1000 \
--volume /etc/passwd:/etc/passwd:ro --volume /etc/group:/etc/group:ro \
--device /dev/fuse \
--security-opt apparmor=unconfined \
-p 5590:5590 \
rclone/rclone \
mount remote-crypt:/media /data \
--allow-other \
--rc --rc-addr localhost:5590 --rc-no-auth

Describe the results you received:

The rclone command seems to be working, but the mount isn't exposed to the host, apparently.
2021/05/04 14:02:10 NOTICE: Serving remote control on http://localhost:5590/
If you ls ~/data/mount, it'll be empty.

However, it works if you run the podman command with sudo.

Describe the results you expected:

Show the mount in ~/data/mount.

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

It works if you run the podman command with sudo.

Output of podman version:

Version:      3.0.1
API Version:  3.0.0
Go Version:   go1.15.8
Built:        Fri Feb 19 13:56:17 2021
OS/Arch:      linux/amd64

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.19.4
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.0.26-1.fc33.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.26, commit: 777074ecdb5e883b9bec233f3630c5e7fa37d521'
  cpus: 4
  distribution:
    distribution: fedora
    version: "33"
  eventLogger: journald
  hostname: localhost.localdomain
  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.11.12-200.fc33.x86_64
  linkmode: dynamic
  memFree: 5937692672
  memTotal: 8203341824
  ociRuntime:
    name: crun
    package: crun-0.19-1.fc33.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 0.19
      commit: e67a75672412975916dac6b87f8346f870e4b99a
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
  os: linux
  remoteSocket:
    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
    selinuxEnabled: true
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.1.9-1.fc33.x86_64
    version: |-
      slirp4netns version 1.1.9
      commit: 4e37ea557562e0d7a64dc636eff156f64927335e
      libslirp: 4.3.1
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.5.0
  swapFree: 3944370176
  swapTotal: 4100976640
  uptime: 43h 40m 50s (Approximately 1.79 days)
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - registry.centos.org
  - docker.io
store:
  configFile: /home/server/.config/containers/storage.conf
  containerStore:
    number: 10
    paused: 0
    running: 0
    stopped: 10
  graphDriverName: overlay
  graphOptions:
    overlay.mount_program:
      Executable: /usr/bin/fuse-overlayfs
      Package: fuse-overlayfs-1.5.0-1.fc33.x86_64
      Version: |-
        fusermount3 version: 3.9.3
        fuse-overlayfs: version 1.5
        FUSE library version 3.9.3
        using FUSE kernel interface version 7.31
  graphRoot: /home/server/.local/share/containers/storage
  graphStatus:
    Backing Filesystem: btrfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 12
  runRoot: /run/user/1000/containers
  volumePath: /home/server/.local/share/containers/storage/volumes
version:
  APIVersion: 3.0.0
  Built: 1613753777
  BuiltTime: Fri Feb 19 13:56:17 2021
  GitCommit: ""
  GoVersion: go1.15.8
  OsArch: linux/amd64
  Version: 3.0.1

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

podman-3.0.1-1.fc33.x86_64

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

No

[mheon]

Does shared mount propagation work as rootless? @giuseppe @rhatdan

[andreluisos]

Does shared mount propagation work as rootless? @giuseppe @rhatdan

If not, is there a chance this could become a feature request?

[mheon]

If there is such a restriction, I suspect it's at the kernel level, so unfortunately Podman itself won't be able to do much about it.

[giuseppe]

shared and rshared don't work as rootless, that is by design in the kernel as it would allow unprivileged users to create mount on the host.

[mheon]

We should add a check to throw an error when the user tries them, then - having a mount that just doesn't exist because options are unsupported is very confusing.

[andreluisos]

It doesn't hurt asking: is there a workaround?

[giuseppe]

We should add a check to throw an error when the user tries them, then - having a mount that just doesn't exist because options are unsupported is very confusing.

they are still accessible from the podman unshare environment.

It doesn't hurt asking: is there a workaround?

if you go into the podman unshare environment, the current user has full capabilities and can see the mounts propagated by containers.

Unfortunately this cannot propagate mounts to the host, you need to run as root for that.

[rhatdan]

Correct the problem here is the executor or Podman has to have control of the mount namespace. When a rootless user runs podman it mounts within the usernamespace/mount namespace, But when you exit the namespaces, you loose the view. If you use podman unshare, you should then see the propagated namespace. But the hosts mount namespace will never see it.

When running as root, we don't automatically create a userns/mountns since we have SYS_ADMIN privs and are allowed to modify the host mount namespace.

[andreluisos]

Correct the problem here is the executor or Podman has to have control of the mount namespace. When a rootless user runs podman it mounts within the usernamespace/mount namespace, But when you exit the namespaces, you loose the view. If you use podman unshare, you should then see the propagated namespace. But the hosts mount namespace will never see it.

When running as root, we don't automatically create a userns/mountns since we have SYS_ADMIN privs and are allowed to modify the host mount namespace.

--cap-add SYS_ADMIN wouldn't solve the "issue"?

[rhatdan]

No, when you are rootless, you don't have access to REAL SYS_ADMIN. when you specify --cap-add SYS_ADMIN, you are just running a container with Namespaced CAP_SYSADMIN, which gives you this for the User Namespace you are running in, not the hosts user namespace.

[rhatdan]

Remember rootless environments do not provide a way to break out and control the host. The same rules about what a user is allowed to do on a host are preserved.

[andreluisos]

Remember rootless environments do not provide a way to break out and control the host. The same rules about what a user is allowed to do on a host are preserved.

Got it! Thank you all!

[andreluisos]

Another question regarding this: would it be possible to share that mount with other containers in rootless mode?

[giuseppe]

yes, from the podman unshare environment you can share mounts among containers running there

[andreluisos]

Would this be possible to expose the mount to other containers in rootless?