podman image build fails 'bad file descriptor' when given --file - for stdin

[jordansissel]

Issue Description

podman build fails when given -f - for reading a Containerfile via stdin.

Steps to reproduce the issue

Steps to reproduce the issue

1. echo "FROM ubuntu:latest" | podman build -f -

Describe the results you received

% echo "FROM ubuntu:latest" | podman build -f -
ERRO[0000] 1 error occurred:
	* lstat /dev/fd/3: bad file descriptor


Error: Post "http://d/v4.3.1/libpod/build?dockerfile=%5B%22%2Fprivate%2Fvar%2Ffolders%2Fft%2Fp7btchb90gg8ps2hwtnk8_7c0000gn%2FT%2Fbuild459898844%22%5D&forcerm=1&identitylabel=1&idmappingoptions=%7B%22HostUIDMapping%22%3Atrue%2C%22HostGIDMapping%22%3Atrue%2C%22UIDMap%22%3A%5B%5D%2C%22GIDMap%22%3A%5B%5D%2C%22AutoUserNs%22%3Afalse%2C%22AutoUserNsOpts%22%3A%7B%22Size%22%3A0%2C%22InitialSize%22%3A0%2C%22PasswdFile%22%3A%22%22%2C%22GroupFile%22%3A%22%22%2C%22AdditionalUIDMappings%22%3Anull%2C%22AdditionalGIDMappings%22%3Anull%7D%7D&isolation=3&jobs=1&layers=1&networkmode=0&nsoptions=%5B%7B%22Name%22%3A%22user%22%2C%22Host%22%3Atrue%2C%22Path%22%3A%22%22%7D%5D&omithistory=0&outputformat=application%2Fvnd.oci.image.manifest.v1%2Bjson&platform=%2F&pullpolicy=missing&rm=1&shmsize=67108864&t=": io: read/write on closed pipe

Describe the results you expected

It should build the container image.

podman info output

host:
  arch: arm64
  buildahVersion: 1.28.0
  cgroupControllers:
  - cpu
  - io
  - memory
  - pids
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.1.5-1.fc37.aarch64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.5, commit: '
  cpuUtilization:
    idlePercent: 99.9
    systemPercent: 0.07
    userPercent: 0.04
  cpus: 1
  distribution:
    distribution: fedora
    variant: coreos
    version: "37"
  eventLogger: journald
  hostname: localhost.localdomain
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 1000000
    uidmap:
    - container_id: 0
      host_id: 501
      size: 1
    - container_id: 1
      host_id: 100000
      size: 1000000
  kernel: 6.1.9-200.fc37.aarch64
  linkmode: dynamic
  logDriver: journald
  memFree: 1633656832
  memTotal: 2050248704
  networkBackend: netavark
  ociRuntime:
    name: crun
    package: crun-1.7.2-3.fc37.aarch64
    path: /usr/bin/crun
    version: |-
      crun version 1.7.2
      commit: 0356bf4aff9a133d655dc13b1d9ac9424706cac4
      rundir: /run/user/501/crun
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +LIBKRUN +WASM:wasmedge +YAJL
  os: linux
  remoteSocket:
    exists: true
    path: /run/user/501/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_AUDIT_WRITE,CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_MKNOD,CAP_NET_BIND_SERVICE,CAP_NET_RAW,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: true
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: true
  serviceIsRemote: true
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.2.0-8.fc37.aarch64
    version: |-
      slirp4netns version 1.2.0
      commit: 656041d45cfca7a4176f6b7eed9e4fe6c11e8383
      libslirp: 4.7.0
      SLIRP_CONFIG_VERSION_MAX: 4
      libseccomp: 2.5.3
  swapFree: 0
  swapTotal: 0
  uptime: 5h 47m 18.00s (Approximately 0.21 days)
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  volume:
  - local
registries:
  search:
  - docker.io
store:
  configFile: /var/home/core/.config/containers/storage.conf
  containerStore:
    number: 140
    paused: 0
    running: 0
    stopped: 140
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /var/home/core/.local/share/containers/storage
  graphRootAllocated: 106825756672
  graphRootUsed: 11541172224
  graphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 69
  runRoot: /run/user/501/containers
  volumePath: /var/home/core/.local/share/containers/storage/volumes
version:
  APIVersion: 4.3.1
  Built: 1668178831
  BuiltTime: Fri Nov 11 07:00:31 2022
  GitCommit: ""
  GoVersion: go1.19.2
  Os: linux
  OsArch: linux/arm64
  Version: 4.3.1

### Podman in a container

No

### Privileged Or Rootless

Rootless

### Upstream Latest Release

No

### Additional environment details

OS is macOS Ventura 13.2 on an m2 MacBook Air

### Additional information

_No response_

[rhatdan]

This is working in podman 4.4

$ echo "from scratch" | podman build -
STEP 1/1: FROM scratch
COMMIT
--> 6e28a6cb8a7
6e28a6cb8a72e04fffc6a10c197cddfc451d1dadde32cca9c50d3e951070c50a
$ echo "from alpine" | podman build -
STEP 1/1: FROM alpine
COMMIT
--> 042a816809a
042a816809aac8d0f7d7cacac7965782ee2ecac3f21bcf9f24b1de1a7387b769

[sstosh]

I reproduced a similar issue in podman version 4.5.0-dev rootless remote.
But, an error message is different from the report.
(bud file descriptor -> permission denied)

If libpod_lock is already created,
echo "from alpine" | podman-remote build -f - will be failed due to permission denied.
On the other hand, build - is successed.

$ ls -l /dev/shm/
total 168
-rw-------. 1 root root 82488 Feb 13 10:53 libpod_lock
-rw-------. 1 test test 82488 Feb 13 17:28 libpod_rootless_lock_1000

$ echo "from alpine" | podman-remote build -f -
ERRO[0000] 1 error occurred:
        * open /dev/shm/libpod_lock: permission denied


Error: Post "http://d/v4.5.0/libpod/build?dockerfile=%5B%22%2Fvar%2Ftmp%2Fbuild4259015452%22%5D&forcerm=1&httpproxy=1&identitylabel=1&idmappingoptions=%7B%22HostUIDMapping%22%3Atrue%2C%22HostGIDMapping%22%3Atrue%2C%22UIDMap%22%3A%5B%5D%2C%22GIDMap%22%3A%5B%5D%2C%22AutoUserNs%22%3Afalse%2C%22AutoUserNsOpts%22%3A%7B%22Size%22%3A0%2C%22InitialSize%22%3A0%2C%22PasswdFile%22%3A%22%22%2C%22GroupFile%22%3A%22%22%2C%22AdditionalUIDMappings%22%3Anull%2C%22AdditionalGIDMappings%22%3Anull%7D%7D&isolation=3&jobs=1&layers=1&networkmode=0&nsoptions=%5B%7B%22Name%22%3A%22user%22%2C%22Host%22%3Atrue%2C%22Path%22%3A%22%22%7D%5D&omithistory=0&outputformat=application%2Fvnd.oci.image.manifest.v1%2Bjson&platform=%2F&pullpolicy=missing&rm=1&seccomp=%2Fusr%2Fshare%2Fcontainers%2Fseccomp.json&shmsize=67108864&t=": io: read/write on closed pipe

$ echo "from alpine" | podman-remote build -
STEP 1/1: FROM alpine
COMMIT
--> b2aa39c304c
b2aa39c304c27b96c1fef0c06bee651ac9241d49c4fe34381cab8453f9a89c7d

$ podman version
Client:       Podman Engine
Version:      4.5.0-dev
API Version:  4.5.0-dev
Go Version:   go1.19.5
Git Commit:   f099c1fc9a840067ac0c98c1770a45fd378a07d8
Built:        Mon Feb 13 10:53:19 2023
OS/Arch:      linux/amd64

[rhatdan]

P

[jordansissel]

@rhatdan You tested something that I didn't report. Please reopen.

You used: podman build - ("Context" is set to "-")

I used podman build -f - ("--file" flag is given "-")

I'm just following the documentation which says, for the -f/--file flag:

Specifying the option -f - causes the Containerfile contents to be read from stdin.

Of note:

• This fails, as I reported: echo "from scratch" | podman build -f -
• This succeeds, as you reported: echo "from scratch" | podman build -

Side note: After filling this issue, I attempted to test this on v4.4.1, but it's unclear if I was successful in upgrading. I have a 4.4.1 client, but the 4.4.1 client using podman machine init and creates a v4.3.1 server and the podman documentation instructs me to read coreOS documentation about upgrades within the machine, and those documents are ... unclear ... as to how to instruct it to do any sort of upgrade activity. I decided to exclude this from my report to avoid causing confusion, and I'd prefer to avoid diving into the "4.4.1 creates a 4.3.1 machine" oddity ;)

[jordansissel]

(As a side quest, I looked into the podman build documentation and I was unable to find any behavior description for when "-" is provided as the context parameter. I'm mostly posting this for posterity should anyone else end up in this issue and don't want to dive into "What does a single dash mean when used as context?" in this issue)

[jordansissel]

I am able to reproduce this now on Linux and tested a hypothesis that this is a problem specific to podman machine usage.

On Linux, my example does not fail because it presumably runs on the host natively. On macOS, it fails. One major difference is Linux is native and macOS uses podman machine.

If I create a podman machine on Linux and instruct podman to use this virtual machine, it fails on LIux with a slightly different error than my original report (on macOS) and is very similar in error to #17495.

I'll follow up on #17495 for this assuming that my issue is similar.