Bug 1996757

Don't the docs already mentioned that `su --login` works?

(In reply to Valentin Rothberg from comment #3)
> Don't the docs already mentioned that `su --login` works?

No, actually the docs specifically call out that this doesn't work:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/building_running_and_managing_containers/assembly_starting-with-containers_building-running-and-managing-containers#proc_setting-up-rootless-containers_assembly_starting-with-containers
---
"NOTE
    Do not use su or su - commands because these commands do not set the correct environment variables. Use your Red Hat Customer Portal credentials."
---

Side note - the last sentence is incorrect and has already been reported via Bug 1996142


Using 'su -', 'su -l, 'su --login', etc. doesn't work

# su user1 -c 'podman images'
ERRO[0000] XDG_RUNTIME_DIR directory "/run/user/0" is not owned by the current user 

# su - user1 -c 'podman images'
Error: error creating tmpdir: mkdir /run/user/1000: permission denied

# ssh user1@localhost podman images
user1@localhost's password: 
REPOSITORY                            TAG         IMAGE ID      CREATED       SIZE
registry.access.redhat.com/ubi8       latest      ad42391b9b46  2 weeks ago   234 MB
registry.access.redhat.com/ubi8-init  latest      9bbdcc2d3f32  2 months ago  251 MB

# machinectl -q shell user1@ /usr/bin/podman images
REPOSITORY                            TAG         IMAGE ID      CREATED       SIZE
registry.access.redhat.com/ubi8       latest      ad42391b9b46  2 weeks ago   234 MB
registry.access.redhat.com/ubi8-init  latest      9bbdcc2d3f32  2 months ago  251 MB

Noting logging in with a login shell explicitly works on a fresh out-of-box RHEL8.4 image:

# useradd podman

# grep podman /etc/sub{u,g}id
/etc/subuid:podman:431072:65536
/etc/subgid:podman:431072:65536

# su -l podman

$ id
uid=1002(podman) gid=1002(podman) groups=1002(podman) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

$ podman run --rm docker.io/hello-world

Hello from Docker!
This message shows that your installation appears to be working correctly.
- - - - 8< - - - -

$ exit

# su podman -l -c "podman info"
host:
  arch: amd64
  buildahVersion: 1.19.8
  cgroupManager: cgroupfs
  cgroupVersion: v1
  conmon:
    package: conmon-2.0.26-1.module+el8.4.0+10607+f4da7515.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.26, commit: b883692702312720058141f16b6002ab26ead2e7'
  cpus: 2
  distribution:
    distribution: '"rhel"'
    version: "8.4"
  eventLogger: file
  hostname: rhel8
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1002
      size: 1
    - container_id: 1
      host_id: 431072
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1002
      size: 1
    - container_id: 1
      host_id: 431072
      size: 65536
  kernel: 4.18.0-305.el8.x86_64
  linkmode: dynamic
  memFree: 7581159424
  memTotal: 8146018304
  ociRuntime:
    name: runc
    package: runc-1.0.0-70.rc92.module+el8.4.0+10607+f4da7515.x86_64
    path: /usr/bin/runc
    version: 'runc version spec: 1.0.2-dev'
  os: linux
  remoteSocket:
    path: /tmp/podman-run-1002/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_NET_RAW,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.8-1.module+el8.4.0+10607+f4da7515.x86_64
    version: |-
      slirp4netns version 1.1.8
      commit: d361001f495417b880f20329121e3aa431a8f90f
      libslirp: 4.3.1
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.5.1
  swapFree: 0
  swapTotal: 0
  uptime: 4m 30.66s
registries:
  search:
  - registry.access.redhat.com
  - registry.redhat.io
  - docker.io
store:
  configFile: /home/podman/.config/containers/storage.conf
  containerStore:
    number: 0
    paused: 0
    running: 0
    stopped: 0
  graphDriverName: overlay
  graphOptions:
    overlay.mount_program:
      Executable: /usr/bin/fuse-overlayfs
      Package: fuse-overlayfs-1.4.0-2.module+el8.4.0+10607+f4da7515.x86_64
      Version: |-
        fusermount3 version: 3.2.1
        fuse-overlayfs: version 1.4
        FUSE library version 3.2.1
        using FUSE kernel interface version 7.26
  graphRoot: /home/podman/.local/share/containers/storage
  graphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 1
  runRoot: /tmp/podman-run-1002/containers
  volumePath: /home/podman/.local/share/containers/storage/volumes
version:
  APIVersion: 3.0.0
  Built: 1623138726
  BuiltTime: Tue Jun  8 03:52:06 2021
  GitCommit: ""
  GoVersion: go1.15.13
  OsArch: linux/amd64
  Version: 3.0.2-dev

Is there anyway we can make Podman smarter about realizing this situation?  

XDG_RUNTIME_DIR is not writable, and the last field is a UID that does not match the current UID, then give a nice error message, saying su and sudo not supported, try su -i and sudo -l

@arajan can you put your thinking cap on concerning Dan's last comment?  If you can come up with something, please create a jira card and we'll include in a later version of Podman.

That comment was aimed more at Matt and Giuseppe.

Didn't Aditya just add a warning that fires if the systemd user session isn't up? That doesn't cover *every* case, but it does handle cgroupsv2 systems quite nicely.

I think that the XDG_RUNTIME_DIR warning is probably only necessary if Podman is being run for the first time - otherwise, the systemd session not active warning is probably more applicable. I'm actually not sure what we do in the case that XDG_RUNTIME_DIR exists but is not writable - maybe we already fall back to a rundir in `/tmp`?

Yes, and the problem with what we currently have, is it is very little actionable information,  We could warn at this level and mention more information like to use su -l, or sudo -i

Something like:

"required login session. Note: For su or sudo try `su -i`|`sudo -l`"

@dwalsh We can have a check for `XDG_RUNTIME_DIR` if its writable or not while we are creating the user namespace. I'll confirm Matt's doubt and if no blockers are found I'll just open a PR.

The problem is that I'm pretty sure you can get things mostly working even without a session if you place directories in the right place, and (potentially) set cgroups the right way (if on a CGv2 system). I know for certain there are a lot of people running Podman without login sessions on v1 systems, who have been happily plugging along with this configuration for years. I don't think we can just start throwing warnings on all of their installations warning them that their configuration won't work when it clearly does.

Error messages still make sense to me, but we need to make sure they're restricted to things we know won't work.

So the question is can we react to this failure and change the location of the TMPFS content?
Basically change the database.

Unsafe unless all containers have been removed - existing containers may reference the old rundir in the DB, and we will lose the current state of any running containers.

If there is no running containers, then it would not be an issue, correct?  Would a newly created container get the /tmp/podman* content?

Is this RFE still considered to be a 'won't fix'? 

Our State Street customer has been using 'su' privileges in Tower 3.8x, and are now planning to roll over to AAP 2.1x; however, since they cannot use sudo in AAP 2.1x, they are unable to run the installer successfully. 

Is there a method we can implement for using 'su' priviliges for the AAP 2.1x installer? For this customer there is no other option other than using the su privileges.

@dwalsh thoughts about the prior comment for State Bank?

@juholmes This BZ is indeed a won't fix, it's been almost a year since it has been closed.  If Dan isn't able to give you a quick answer, please create a new BZ with the specifics of the issue that State Street is facing.

Ack Tom, I'll open a new BZ by eod tommorrow if there's no response by then.

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days