Bug 1996757 - [RFE] Allow for `su` or `su -` to be supported methods to access rootless podman, not only SSH [NEEDINFO]
Summary: [RFE] Allow for `su` or `su -` to be supported methods to access rootless pod...
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: podman
Version: 8.4
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Aditya R
QA Contact: atomic-bugs@redhat.com
Depends On:
Blocks: 1186913
TreeView+ depends on / blocked
Reported: 2021-08-23 15:27 UTC by Robb Manes
Modified: 2022-05-17 19:50 UTC (History)
17 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2021-08-25 14:54:17 UTC
Type: Enhancement
Target Upstream Version:
arajan: needinfo? (robb.manes)
jnovy: needinfo? (gscrivan)
tsweeney: needinfo? (dwalsh)

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-94486 0 None None None 2021-08-23 15:29:59 UTC
Red Hat Knowledge Base (Solution) 6204862 0 None None None 2021-08-23 15:27:44 UTC

Description Robb Manes 2021-08-23 15:27:45 UTC
Description of problem:
Currently, the only supported method of being able to execute podman commands as a non-root user is via accessing the system via `ssh`, either by using `ssh` to get to the machine or using `ssh localhost`.

A number of automation tools, and quite a number of our customers, use utilities like `su` to access users, and scripting things like `ssh localhost` is very difficult to do in some pipelines (such as Jenkins).  It would be ideal to allow users to use a method such as `su` or `su -` to access their user and, provided it is properly configured, run rootless podman commands.

This is technically possible already provided a user manually sets up an environment that fulfills most or all of the values that SSH fulfills for the user, but it has been stated that accessing podman via rootless via SSH is not tested and not expected to work.

This feature request could be complete if one of the two scenarios were to be resolved:

- Red Hat documents steps necessary for the most common configurations of non-root users to access podman and declares them a supported use-case.
- Red Hat provides some method of making rootless work out-of-the-box for `su` or `su -`, which would be very difficult based on rootless's reliance on XDG variables, DBUS variables, and user namespaces that all must be manually configured.

A KCS solution exists stating A) this is unsupported and B) the common steps to make this work in an unsupported manner:


Review of the steps in the event we choose to investigate this feature further would be welcome.

Version-Release number of selected component (if applicable):
Any version of podman on RHEL7 or RHEL8, or even upstream.

How reproducible:
Every time

Comment 3 Valentin Rothberg 2021-08-23 16:20:56 UTC
Don't the docs already mentioned that `su --login` works?

Comment 4 Derrick Ornelas 2021-08-23 17:44:21 UTC
(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:

    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

Comment 8 Robb Manes 2021-08-24 19:05:46 UTC
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

# 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"
  arch: amd64
  buildahVersion: 1.19.8
  cgroupManager: cgroupfs
  cgroupVersion: v1
    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: '"rhel"'
    version: "8.4"
  eventLogger: file
  hostname: rhel8
    - container_id: 0
      host_id: 1002
      size: 1
    - container_id: 1
      host_id: 431072
      size: 65536
    - 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
    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
    path: /tmp/podman-run-1002/podman/podman.sock
    apparmorEnabled: false
    rootless: true
    seccompEnabled: true
    selinuxEnabled: true
    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
      libseccomp: 2.5.1
  swapFree: 0
  swapTotal: 0
  uptime: 4m 30.66s
  - registry.access.redhat.com
  - registry.redhat.io
  - docker.io
  configFile: /home/podman/.config/containers/storage.conf
    number: 0
    paused: 0
    running: 0
    stopped: 0
  graphDriverName: overlay
      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
    Backing Filesystem: xfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
    number: 1
  runRoot: /tmp/podman-run-1002/containers
  volumePath: /home/podman/.local/share/containers/storage/volumes
  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

Comment 11 Daniel Walsh 2021-08-25 17:28:16 UTC
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

Comment 12 Tom Sweeney 2021-08-25 18:51:13 UTC
@arajan@redhat.com 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.

Comment 13 Daniel Walsh 2021-08-25 18:52:46 UTC
That comment was aimed more at Matt and Giuseppe.

Comment 14 Matthew Heon 2021-08-25 20:36:14 UTC
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`?

Comment 16 Daniel Walsh 2021-08-26 09:29:17 UTC
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`"

Comment 17 Aditya R 2021-08-26 10:09:08 UTC
@dwalsh@redhat.com 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.

Comment 18 Matthew Heon 2021-08-26 13:39:46 UTC
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.

Comment 20 Daniel Walsh 2021-08-27 19:41:59 UTC
So the question is can we react to this failure and change the location of the TMPFS content?
Basically change the database.

Comment 21 Matthew Heon 2021-08-27 20:07:21 UTC
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.

Comment 22 Daniel Walsh 2021-08-27 20:13:12 UTC
If there is no running containers, then it would not be an issue, correct?  Would a newly created container get the /tmp/podman* content?

Comment 23 juholmes 2022-05-17 18:37:47 UTC
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.

Comment 24 Tom Sweeney 2022-05-17 19:46:51 UTC
@dwalsh@redhat.com thoughts about the prior comment for State Bank?

@juholmes@redhat.com 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.

Comment 25 juholmes 2022-05-17 19:50:21 UTC
Ack Tom, I'll open a new BZ by eod tommorrow if there's no response by then.

Note You need to log in before you can comment on or make changes to this bug.