Windows - Podman REST API over named windows pipe is not consistent with the cli

[iongion]

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

/kind bug

Description

API calls over windows named pipe are not behaving the same as the cli commands, producing different results, cli is proper, the api is not.

Steps to reproduce the issue:

1. start podman machine podman machine start
2. create a container from cli podman run -dt -p 8889:80/tcp docker.io/library/httpd:latest
3. list containers using cli podman run -dt -p 8889:80/tcp docker.io/library/httpd:latest (it will return one)
4. use the test script to read the containers using the windows named pipe api (it will return an empty list)

Describe the results you received:

• empty list

Describe the results you expected:

• the same as when using the cli

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

Output of podman version:

4.0.3

Output of podman info --debug:

podman info --debug
time="2022-04-14T11:56:51-07:00" level=warning msg="Failed to retrieve default tmp dir: invalid image_copy_tmp_dir value \"/var/tmp\" (relative paths are not accepted)"
host:
  arch: amd64
  buildahVersion: 1.24.3
  cgroupControllers: []
  cgroupManager: cgroupfs
  cgroupVersion: v1
  conmon:
    package: conmon-2.1.0-2.fc35.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.0, commit: '
  cpus: 8
  distribution:
    distribution: fedora
    variant: container
    version: "35"
  eventLogger: file
  hostname: win10
  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.10.16.3-microsoft-standard-WSL2
  linkmode: dynamic
  logDriver: journald
  memFree: 4545036288
  memTotal: 6629613568
  networkBackend: netavark
  ociRuntime:
    name: crun
    package: crun-1.4.4-1.fc35.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 1.4.4
      commit: 6521fcc5806f20f6187eb933f9f45130c86da230
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +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: true
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.1.12-2.fc35.x86_64
    version: |-
      slirp4netns version 1.1.12
      commit: 7a104a101aa3278a2152351a082a6df71f57c9a3
      libslirp: 4.6.1
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.5.3
  swapFree: 2147483648
  swapTotal: 2147483648
  uptime: 30m 49.72s
plugins:
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  volume:
  - local
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - docker.io
  - quay.io
store:
  configFile: /home/user/.config/containers/storage.conf
  containerStore:
    number: 6
    paused: 0
    running: 0
    stopped: 6
  graphDriverName: overlay
  graphOptions:
    overlay.mount_program:
      Executable: /usr/bin/fuse-overlayfs
      Package: fuse-overlayfs-1.7.1-2.fc35.x86_64
      Version: |-
        fusermount3 version: 3.10.5
        fuse-overlayfs: version 1.7.1
        FUSE library version 3.10.5
        using FUSE kernel interface version 7.31
  graphRoot: /home/user/.local/share/containers/storage
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 1
  runRoot: /run/user/1000/containers
  volumePath: /home/user/.local/share/containers/storage/volumes
version:
  APIVersion: 4.0.3
  Built: 1648837274
  BuiltTime: Fri Apr  1 11:21:14 2022
  GitCommit: ""
  GoVersion: go1.16.15
  OsArch: linux/amd64
  Version: 4.0.3

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

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

• Windows 10 running in qemu/gnome boxes, on a nested virtualization enabled host running linux kernel 5.16.14-1

Used this simple nodejs script to test

const http = require('http');
const socketPath = "//./pipe/podman-machine-default";

const fetch = function(options) {
    return new Promise((resolve, reject) => {
        const request = {
            url: 'http://d',
            method: 'GET',
            socketPath,
            ...(options || {})
        }
        const req = http.request(request, res => {
            console.log(`statusCode: ${res.statusCode}`)
            res.on('data', d => {
                resolve({
                    statusCode: res.statusCode,
                    body: d.toString("utf-8"),
                    headers: res.headers,
                });
            });
        });
        req.on('error', reject);
        req.end();
    });
}

// Test ping
fetch({ path: "/v3.0.0/libpod/_ping" }).then((response) => {
    console.debug("Request done => response", response);
}).catch((error) => {
    console.error("Request error", error);
});

// 1.0 - start podman machine `podman machine start`
// 2.0 - create a container from cli `podman run -dt -p 8889:80/tcp docker.io/library/httpd:latest`
// 3.0 - podm
//
// The output will be
// 
// time="2022-04-14T11:49:26-07:00" level=warning msg="Failed to retrieve default tmp dir: invalid image_copy_tmp_dir value \"/var/tmp\" (relative paths are not accepted)"
// CONTAINER ID  IMAGE                           COMMAND           CREATED        STATUS            PORTS                 NAMES
// a153716cc9ad  docker.io/library/httpd:latest  httpd-foreground  8 seconds ago  Up 9 seconds ago  0.0.0.0:8889->80/tcp  trusting_jepsen
// 


// Test containers list using API
fetch({ path: "/v3.0.0/libpod/containers/json" }).then((response) => {
    console.debug("Request done => response", response);
    // It will return an empty list 
    /*
    {
        statusCode: 200,
        body: '[]\n',
        headers: {
            'api-version': '1.40',
            'content-type': 'application/json',
            'libpod-api-version': '4.0.3',
            server: 'Libpod/4.0.3 (linux)',
            'x-reference-id': '0xc000011218',
            date: 'Thu, 14 Apr 2022 18:51:37 GMT',
            'content-length': '3',
            connection: 'close'
        }
    }
    */
}).catch((error) => {
    console.error("Request error", error);
});

[Luap99]

@n1hility PTAL

Is it possible that the pipe is connected to the root socket and the cli is using the rootless socket or the other way around?

[n1hility]

@Luap99 will check it out - should be consistent now with preferring rootless first

[n1hility]

Fix PRs created, sorry for the oversight!

[n1hility]

@iongion Here is a special build of 4.0.3 with the fix if you want something for testing:

https://github.com/n1hility/podman-builds/blob/main/podman-v4.0.3-dev.msi

sha1sum:
efb0b0414a8893c989889e2338eac3f620b2eec3 podman-v4.0.3-dev.msi

[iongion]

Awesome, thank you Jason, that did it!