Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be unavailable on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1570195 - init container behavior changes based on main container privileged setting
Summary: init container behavior changes based on main container privileged setting
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Node
Version: 3.10.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: Seth Jennings
QA Contact: DeShuai Ma
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-04-20 21:00 UTC by Ben Parees
Modified: 2018-04-20 21:34 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-04-20 21:34:02 UTC
Target Upstream Version:

Attachments (Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

Description Ben Parees 2018-04-20 21:00:37 UTC 
Create a pod w/ an init container and a primary container.

Mark the primary container privileged.  Do not mark the init container privileged.

The init container will run as root(or perhaps the image's default user).

Now create a second pod, identical to the first but do NOT make the primary container privileged.

The init container will run as an assigned uid (e.g. 1000600).


I would expect in both cases for the init container to run as an assigned uid.

(Note that the openshift build git-clone init container is currently only working *because* of this bug.  git cloning fails when the git-clone container gets run as a random uid.  I have a fix for that, it will need to go in before/when any fix for this bug goes in, though).
Comment 1 Ben Parees 2018-04-20 21:34:02 UTC 
Jordan explained this behavior to me.  Basically because the pod has to use the privileged SCC, the init containers end up running as their default user.

When the pod doesn't have to use the privileged SCC, the init containers get assigned uids.

I still find it somewhat surprising behavior that changing settings in one container effectively changes the behavior/configuration of another container, but it sounds like it's working as designed.
Note You need to log in before you can comment on or make changes to this bug.