Bug 1254928 - [origin_devexp_603] Can't allow s2i builder image run as a numeric userid belong scc user range
[origin_devexp_603] Can't allow s2i builder image run as a numeric userid bel...
Status: CLOSED CURRENTRELEASE
Product: OpenShift Origin
Classification: Red Hat
Component: Build (Show other bugs)
3.x
Unspecified Unspecified
medium Severity medium
: ---
: ---
Assigned To: Cesar Wong
Wenjing Zheng
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-19 05:13 EDT by DeShuai Ma
Modified: 2015-09-08 16:14 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-09-08 16:14:06 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description DeShuai Ma 2015-08-19 05:13:43 EDT
Description of problem:
When scc/privileged set runAsUser to a range, do s2i build, the builder image userid is belong the range, but the build can't success.

Version-Release number of selected component (if applicable):
openshift v1.0.4-363-gd3cf735-dirty
kubernetes v1.1.0-alpha.0-1605-g44c91b1

How reproducible:
Always

Steps to Reproduce:
1.Set scc/privileged as below:
--skip---
    "runAsUser": {
        "type": "MustRunAsRange",
        "uidRangeMin": 1000,
        "uidRangeMax": 2000
    }
--skip---

2. Edit s2i builder image as below:
---skip---
        "strategy": {
            "type": "Source",
            "sourceStrategy": {
                "from": {
                    "kind": "DockerImage",
                    "name": "deshuai/ruby-20-centos7:user1002"
                }
            }
        }
---skip---

3.Star a build and check the build

Actual results:
3. The build always failed with error:
[fedora@ip-10-7-159-102 2.0]$ oc build-logs ruby-sample-build-12 -n dma1
I0819 07:51:01.600906       1 builder.go:39] $BUILD env var is {"kind":"Build","apiVersion":"v1","metadata":{"name":"ruby-sample-build-12","namespace":"dma1","selfLink":"/oapi/v1/namespaces/dma1/builds/ruby-sample-build-12","uid":"079be952-4647-11e5-bdb7-22000b602c3d","resourceVersion":"4446","creationTimestamp":"2015-08-19T07:50:58Z","labels":{"buildconfig":"ruby-sample-build","name":"ruby-sample-build","template":"application-template-stibuild"},"annotations":{"openshift.io/build.number":"12"}},"spec":{"serviceAccount":"builder","source":{"type":"Git","git":{"uri":"https://github.com/openshift/ruby-hello-world.git"}},"strategy":{"type":"Source","sourceStrategy":{"from":{"kind":"DockerImage","name":"deshuai/ruby-20-centos7:user1002"}}},"output":{"to":{"kind":"DockerImage","name":"172.30.31.152:5000/dma1/origin-ruby-sample:latest"},"pushSecret":{"name":"builder-dockercfg-u88a2"}},"resources":{}},"status":{"phase":"Pending","config":{"kind":"BuildConfig","namespace":"dma1","name":"ruby-sample-build"}}} 
I0819 07:51:01.603031       1 cfg.go:78] Found Docker authentication configuration in ''
I0819 07:51:01.603128       1 cfg.go:50] Problem accessing : stat : no such file or directory
I0819 07:51:01.603415       1 sti.go:93] Creating a new S2I builder with build config: "Builder Image:\t\tdeshuai/ruby-20-centos7:user1002\nSource:\t\t\thttps://github.com/openshift/ruby-hello-world.git\nOutput Image Tag:\t172.30.31.152:5000/dma1/origin-ruby-sample:latest\nEnvironment:\t\tOPENSHIFT_BUILD_NAMESPACE=dma1,OPENSHIFT_BUILD_SOURCE=https://github.com/openshift/ruby-hello-world.git,OPENSHIFT_BUILD_NAME=ruby-sample-build-12\nIncremental Build:\tdisabled\nRemove Old Build:\tdisabled\nForce Pull:\t\tdisabled\nQuiet:\t\t\tdisabled\nLayered Build:\t\tdisabled\nDocker Endpoint:\tunix:///var/run/docker.sock\n"
F0819 07:51:01.603528       1 builder.go:62] Build error: unable to get metadata for deshuai/ruby-20-centos7:user1002

Expected results:
3.The build should success

Additional info:
deshuai/ruby-20-centos7:user1002 Dockerfile is: http://fpaste.org/256610/43997154/
Comment 1 Cesar Wong 2015-08-20 14:10:58 EDT
This is working as designed. The build container must run as root (not the S2I builder image), because it needs to access the Docker socket and do privileged operations like starting a container, committing the container, etc. 

In this case, because you set the privileged SCC to MustRunAsRange, the builder is launched with uid 1000, and it fails.
Comment 2 DeShuai Ma 2015-08-20 22:42:23 EDT
(In reply to Cesar Wong from comment #1)
> This is working as designed. The build container must run as root (not the
> S2I builder image), because it needs to access the Docker socket and do
> privileged operations like starting a container, committing the container,
> etc. 
> 
> In this case, because you set the privileged SCC to MustRunAsRange, the
> builder is launched with uid 1000, and it fails.

I agree with what you said about why this fail.
But just one question, we know that the sti-builder container must run as root, when scc/privileged user policy is MustRunAsRange, shouldn't we judge the user privilege before run the build container? if we know it must fail, we should not let it start, not let it run then fail. how do you think?
Comment 3 Cesar Wong 2015-08-25 21:03:23 EDT
(In reply to DeShuai Ma from comment #2)
> I agree with what you said about why this fail.
> But just one question, we know that the sti-builder container must run as
> root, when scc/privileged user policy is MustRunAsRange, shouldn't we judge
> the user privilege before run the build container? if we know it must fail,
> we should not let it start, not let it run then fail. how do you think?

Most images that we run are configured to run as a default user (could be root, could be something like 1001). However, the default SCC ('privileged') is set to MustRunAsRange. If we prevented a container from running when their set user does not fall within the given range, then we would likely not run any containers. A separate range is assigned to each project.
Comment 4 DeShuai Ma 2015-08-25 22:54:26 EDT
Thanks for answer the question.verify this bug.

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