buildah --creds only checks permissions at GET request then assumes it has POST too

[raz3k]

Description

Steps to reproduce the issue:

1. buildah from --name test scratch
2. buildah commit test test
3. buildah push --creds user:password test docker://registry.local/test:0.1

This is happening when only GET requests are let through and POST and others are behind user/password.

Describe the results you received: Getting image source signatures Copying blob sha256:5f70bf18a086007016e948b04aed3b82103a36bea41755b6cddfaf10ace3c6ef 8 B / 1.00 KiB [>----------------------------------------------------------] 0s unauthorized: authentication required

Describe the results you expected: Getting image source signatures Copying blob sha256:5f70bf18a086007016e948b04aed3b82103a36bea41755b6cddfaf10ace3c6ef 1.00 KiB / 1.00 KiB [======================================================] 0s Copying config sha256:5eb895f64387e15e25dd7f199dd7782747ceba3f26fcb72bcff817d9603313a4 263 B / 263 B [============================================================] 0s Writing manifest to image destination Copying config sha256:5eb895f64387e15e25dd7f199dd7782747ceba3f26fcb72bcff817d9603313a4 0 B / 263 B [--------------------------------------------------------------] 0s Writing manifest to image destination Storing signatures Successfully pushed //registry.local/test:0.1@sha256:b0d5c067f7b5ee463c3687ee6d5d47a28b6c227402cd067e8a57f01675d241e2

Output of rpm -q buildah or apt list buildah:

buildah-1.4-3.gitc8ed967.el7.x86_64

Output of buildah version:

Version:         1.5-dev
Go Version:      go1.10.2
Image Spec:      1.0.0
Runtime Spec:    1.0.0
CNI Spec:        0.4.0
libcni Version:  v0.7.0-alpha1
Git Commit:      c8ed967
Built:           Fri Nov 30 02:48:25 2018
OS/Arch:         linux/amd64

*Output of `cat /etc/release`:**

CentOS Linux release 7.6.1810 (Core)
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"

CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"

CentOS Linux release 7.6.1810 (Core)
CentOS Linux release 7.6.1810 (Core)

Output of uname -a:

Linux centos-cluster-razvan.novalocal 3.10.0-862.11.6.el7.x86_64 #1 SMP Tue Aug 14 21:49:04 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Output of cat /etc/containers/storage.conf:

# storage.conf is the configuration file for all tools
# that share the containers/storage libraries
# See man 5 containers-storage.conf for more information
# The "container storage" table contains all of the server options.
[storage]

# Default Storage Driver
driver = "overlay"

# Temporary storage location
runroot = "/var/run/containers/storage"

# Primary Read/Write location of container storage
graphroot = "/var/lib/containers/storage"

[storage.options]
# Storage options to be passed to underlying storage drivers

# AdditionalImageStores is used to pass paths to additional Read/Only image stores
# Must be comma separated list.
additionalimagestores = [
]

# Size is used to set a maximum size of the container image.  Only supported by
# certain container storage drivers.
size = ""

# OverrideKernelCheck tells the driver to ignore kernel checks based on kernel version
override_kernel_check = "true"

# Remap-UIDs/GIDs is the mapping from UIDs/GIDs as they should appear inside of
# a container, to UIDs/GIDs as they should appear outside of the container, and
# the length of the range of UIDs/GIDs.  Additional mapped sets can be listed
# and will be heeded by libraries, but there are limits to the number of
# mappings which the kernel will allow when you later attempt to run a
# container.
#
# remap-uids = 0:1668442479:65536
# remap-gids = 0:1668442479:65536

# Remap-User/Group is a name which can be used to look up one or more UID/GID
# ranges in the /etc/subuid or /etc/subgid file.  Mappings are set up starting
# with an in-container ID of 0 and the a host-level ID taken from the lowest
# range that matches the specified name, and using the length of that range.
# Additional ranges are then assigned, using the ranges which specify the
# lowest host-level IDs first, to the lowest not-yet-mapped container-level ID,
# until all of the entries have been used for maps.
#
# remap-user = "storage"
# remap-group = "storage"

[storage.options.thinpool]
# Storage Options for thinpool

# autoextend_percent determines the amount by which pool needs to be
# grown. This is specified in terms of % of pool size. So a value of 20 means
# that when threshold is hit, pool will be grown by 20% of existing
# pool size.
# autoextend_percent = "20"

# autoextend_threshold determines the pool extension threshold in terms
# of percentage of pool size. For example, if threshold is 60, that means when
# pool is 60% full, threshold has been hit.
# autoextend_threshold = "80"

# basesize specifies the size to use when creating the base device, which
# limits the size of images and containers.
# basesize = "10G"

# blocksize specifies a custom blocksize to use for the thin pool.
# blocksize="64k"

# directlvm_device specifies a custom block storage device to use for the
# thin pool. Required if you setup devicemapper
# directlvm_device = ""

# directlvm_device_force wipes device even if device already has a filesystem
# directlvm_device_force = "True"

# fs specifies the filesystem type to use for the base device.
# fs="xfs"

# log_level sets the log level of devicemapper.
# 0: LogLevelSuppress 0 (Default)
# 2: LogLevelFatal
# 3: LogLevelErr
# 4: LogLevelWarn
# 5: LogLevelNotice
# 6: LogLevelInfo
# 7: LogLevelDebug
# log_level = "7"

# min_free_space specifies the min free space percent in a thin pool require for
# new device creation to succeed. Valid values are from 0% - 99%.
# Value 0% disables
# min_free_space = "10%"

# mkfsarg specifies extra mkfs arguments to be used when creating the base
# device.
# mkfsarg = ""

# mountopt specifies extra mount options used when mounting the thin devices.
# mountopt = ""

# use_deferred_removal Marking device for deferred removal
# use_deferred_removal = "True"

# use_deferred_deletion Marking device for deferred deletion
# use_deferred_deletion = "True"

# xfs_nospace_max_retries specifies the maximum number of retries XFS should
# attempt to complete IO when ENOSPC (no space) error is returned by
# underlying storage device.
# xfs_nospace_max_retries = "0"

[TomSweeneyRedHat]

@raz3k thanks for the issue report, and this may be due to a lack of tea this morning, but I'm a little unclear on when you're hitting the issue. If I follow your three reproducers, will I hit the issue? I'm having a hard time parsing "GET requests are let through and POST and others are behind username/password".

If by chance you have time, could you install podman, try podman login, enter in your creds and then retry your commands but dropping the --creds option. If you don't have time for that, no worries.

[raz3k]

Hello,

I am using this nginx location /v2/ configuration for proxying, sorry about not giving full details:

          limit_except GET {
            auth_basic           $auth_type;
            auth_basic_user_file /etc/nginx/.htpasswd;
          }

podman login http://registry.local
Username: user
Password:
Login Succeeded!

buildah push test docker://registry.local/test:0.1
Getting image source signatures
Copying blob sha256:5f70bf18a086007016e948b04aed3b82103a36bea41755b6cddfaf10ace3c6ef
 8 B / 1.00 KiB [>----------------------------------------------------------] 0s
unauthorized: authentication required

[raz3k]

Here is my full nginx config.

I wanted to be able to pull without a password and push with a password.

events {
    worker_connections  1024;
}

http {

  map $upstream_http_docker_distribution_api_version $docker_distribution_api_version {
    '' 'registry/2.0';
  }

  upstream registry.local-docker {
    server 127.0.0.1:5001;
  }

  server {
    listen 80;
    server_name registry.local;

    client_max_body_size 0;

    chunked_transfer_encoding on;

    location = /v2/ {
      if ($http_user_agent ~ "^(docker\/1\.(3|4|5(?!\.[0-9]-dev))|Go ).*$" ) {
        return 404;
      }
      limit_except GET HEAD {
        auth_basic           "some_org Restricted Area";
        auth_basic_user_file /etc/nginx/.htpasswd;
      }
      add_header 'Docker-Distribution-Api-Version' $docker_distribution_api_version always;

      proxy_pass                          http://registry.local-docker;
      proxy_set_header  Host              $http_host;
      proxy_read_timeout                  900;
    }

    location ~ "/v2/.+?" {

      if ($http_user_agent ~ "^(docker\/1\.(3|4|5(?!\.[0-9]-dev))|Go ).*$" ) {
        return 404;
      }
      limit_except GET HEAD {
        auth_basic           "some_org Restricted Area";
        auth_basic_user_file /etc/nginx/.htpasswd;
      }
      add_header 'Docker-Distribution-Api-Version' $docker_distribution_api_version always;
      proxy_pass                          http://registry.local-docker;
      proxy_set_header  Host              $http_host;
      proxy_read_timeout                  900;
    }
  }
}

[TomSweeneyRedHat]

@raz3k Thanks for sending along that information. I've been trying to replicate you setup but without luck so far. More questions for you:

1) Can you try running this test with the absolute latest/greatest Buildah? I know there's been some tweaks in the auth code recently there that might have helped this, but I'm doubtful to be honest. But if you've the time to upgrade to 1.6-dev, that would be a good data point.

2) I suspect the issue is the registry doesn't know about your nginx proxy setup and/or podman login and the underlying Buildah authentication code doesn't know about it. Can you tell me the commands you've used to setup and run your registry? FWIW, I've been using https://github.com/containers/buildah/blob/master/tests/test_buildah_authentication.sh to setup a registry server but without nginx layered in.

3) Part of the reason I'm asking about how the registry was setup is seeing podman login working with http:// in the address. Regardless you can just stick with the --creds command going forward until we can figure out what's what.

Thanks!

[rhatdan]

Closing because of lack of response. Please open if you want us to continue to work on this issue.