podman secrets --driver=pass hardware token

[mcodev31]

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

/kind bug

Description

secrets with --driver=pass uses new gpg-agent (systemd) causing hardware tokens like yubikey to not work (since they require user authentication)

Steps to reproduce the issue:

1. Create password store using gpg key with hardware token e.g.:
   https://support.yubico.com/hc/en-us/articles/360013790259-Using-Your-YubiKey-with-OpenPGP
2. Create podman secret

echo test1 | podman secret create --driver=pass pass_secret -
a461f4dee15d5e915cc686ff2

3. Read secret in container

podman run --rm -it --secret pass_secret alpine cat /run/secrets/pass_secret

Describe the results you received:
Error: a461f4dee15d5e915cc686ff2: no secret data with ID

Describe the results you expected:
test1

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

This fixes the issue:

rm ~/.gnupg/S.gpg-agent*
ln -s {$XDG_RUNTIME_DIR/gnupg/,~/.gnupg/}S.gpg-agent

Although I would not say this is a good solution.

strace shows podman trying to access /run/user/0 probably in order to read /run/user/0/gnupg/S.gpg-agent rather than ${XDG_RUNTIME_DIR}/gnupg/S.gpg-agent of user 1000 so I suspect that this is a user namespace problem, but have not verified.

Output of podman version:

Version:      3.4.4
API Version:  3.4.4
Go Version:   go1.17.3
Built:        Thu Jan  1 01:00:00 1970
OS/Arch:      linux/amd64

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.23.1
  cgroupControllers:
  - memory
  - pids
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: 'conmon: /usr/bin/conmon'
    path: /usr/bin/conmon
    version: 'conmon version 2.0.25, commit: unknown'
  cpus: 12
  distribution:
    codename: jammy
    distribution: ubuntu
    version: "22.04"
  eventLogger: journald
  hostname: redacted
  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.15.0-22-generic
  linkmode: dynamic
  logDriver: journald
  memFree: 59369926656
  memTotal: 67339329536
  ociRuntime:
    name: crun
    package: 'crun: /usr/bin/crun'
    path: /usr/bin/crun
    version: |-
      crun version 0.17
      commit: 0e9229ae34caaebcb86f1fde18de3acaf18c6d9a
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
  os: linux
  remoteSocket:
    exists: true
    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
    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: 4294963200
  swapTotal: 4294963200
  uptime: 2h 59m 54.93s (Approximately 0.08 days)
plugins:
  log:
  - k8s-file
  - none
  - journald
  network:
  - bridge
  - macvlan
  volume:
  - local
registries:
  search:
  - redacted
store:
  configFile: /home/redacted/.config/containers/storage.conf
  containerStore:
    number: 3
    paused: 0
    running: 1
    stopped: 2
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /home/redacted/.local/share/containers/storage
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 28
  runRoot: /run/user/1000/containers
  volumePath: /home/redacted/.local/share/containers/storage/volumes
version:
  APIVersion: 3.4.4
  Built: 0
  BuiltTime: Thu Jan  1 01:00:00 1970
  GitCommit: ""
  GoVersion: go1.17.3
  OsArch: linux/amd64
  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 amd64 [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)

Yes/No
Latest on ubuntu jammy, have not compiled 4.0.x

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

[mheon]

@ashley-cui PTAL

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@cdoern @ashley-cui Any movement on this?

[cdoern]

@rhatdan I have a PR open in c/common but the tests are near impossible. the fix works I know that so I might look for a way to merge with minimal new tests b/c the more I try to make a test the more I break other things...

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[cdoern]

Coming back to this during this week

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@cdoern any update?

[k33pn3xtlvl]

Is there an update here? I unfortunately also have the problem.

[rhatdan]

@ashley-cui PTAL

[cdoern]

I have a pr open for this but the issue is, it's not testable

[rhatdan]

@k33pn3xtlvl Care to test @cdoern PR? @cdoern what is the PR?

[lex-ibm]

Has this issue gone stale?

[cdoern]

This is the commit @rhatdan cdoern/common@98cfad7 the issue is lack of testability.

[rhatdan]

Did it get merged? Is there a PR? Just don't add a test and we can ask users like @lex-ibm to test it out.

[lex-ibm]

Count me in

[uosis]

Underlying problem here is that when gpg is invoked by podman, it does not detect running gpg-agent (with socket in /run) but instead launches a new agent with socket in .gnupg. New agent obviously has no keys, so decryption fails.

It is not clear to me why agent is not found - probably something to do with the context in which podman invokes gpg.

A workaround is to put the following text in ~/.gnupg/S.gpg-agent:

%Assuan%
socket=/run/user/1000/gnupg/S.gpg-agent

After this gpg is able to find existing agent, and decryption works as expected.

[rhatdan]

Is this an environement variable thing? Do we need to pass a Environment variable from the podman environment through to the GPG to allow it to find it. I believe by default we remove the environment when we exec GPG.

[uosis]

Is this an environement variable thing?

I don't think so - GPG uses hardcoded socket paths, and according to here https://github.com/containers/common/blob/main/pkg/secrets/passdriver/passdriver.go#L162, podman passes through environment variables anyway.