Bug 1723248 - Incorrect error returned when exec'ing to a pod that has been deleted
Summary: Incorrect error returned when exec'ing to a pod that has been deleted
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: kube-apiserver
Version: 4.3.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
: 4.3.0
Assignee: Michal Fojtik
QA Contact: zhou ying
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-06-24 02:13 UTC by Clayton Coleman
Modified: 2020-01-23 11:04 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-01-23 11:04:11 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github openshift apiserver-library-go pull 11 0 'None' closed Bug 1723248: do not wrap not found when getting a pod 2020-02-23 10:33:16 UTC
Red Hat Product Errata RHBA-2020:0062 0 None None None 2020-01-23 11:04:41 UTC

Description Clayton Coleman 2019-06-24 02:13:17 UTC
From client-go code against a 3.11 server (from the cluster-bot) if the pod is deleted it looks like something in the middle (probably admission plugin) is wrapping the 404 with a 403.  It should not wrap, and should return pod "launch-aws" not found.

2019/06/23 22:08:27 Unable to retrieve config contents for ci-ln-x4h7l62/launch-aws: pods "launch-aws" is forbidden: pods "launch-aws" not found

Set to high because it may still be broken in 4.1/4.2/upstream.

Comment 1 Clayton Coleman 2019-06-24 02:14:05 UTC
https://github.com/openshift/origin/blob/release-3.11/pkg/security/apiserver/admission/sccadmission/scc_exec.go#L53-L56

    pod, err := d.client.Core().Pods(a.GetNamespace()).Get(a.GetName(), metav1.GetOptions{})
    if err != nil {
        return admission.NewForbidden(a, err)
    }

It should properly return not found.

Comment 7 zhou ying 2019-12-06 09:12:34 UTC
Confirmed with payload: 4.3.0-0.nightly-2019-12-05-213858, the issue has fixed:

[root@dhcp-140-138 oc-client]# oc get po 
NAME                           READY   STATUS      RESTARTS   AGE
django-psql-example-1-build    0/1     Completed   0          2m1s
django-psql-example-1-cx7wf    1/1     Running     0          40s
django-psql-example-1-deploy   0/1     Completed   0          48s
postgresql-1-deploy            0/1     Completed   0          2m
postgresql-1-qxf2j             1/1     Running     0          112s
[root@dhcp-140-138 oc-client]# oc delete po postgresql-1-qxf2j
pod "postgresql-1-qxf2j" deleted

[root@dhcp-140-138 oc-client]# oc describe po/postgresql-1-qxf2j 
Error from server (NotFound): pods "postgresql-1-qxf2j" not found

Comment 9 errata-xmlrpc 2020-01-23 11:04:11 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:0062


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