Skip to Content.
Sympa Menu

grouper-users - RE: [grouper-users] Grouper 2.5 on Openshift

Subject: Grouper Users - Open Discussion List

List archive

RE: [grouper-users] Grouper 2.5 on Openshift

Chronological Thread 
  • From: "Black, Carey M." <>
  • To: Darren Boss <>, Oliver Trieu <>
  • Cc: "" <>
  • Subject: RE: [grouper-users] Grouper 2.5 on Openshift
  • Date: Fri, 29 May 2020 20:40:31 +0000
  • Arc-authentication-results: i=1; 1; spf=pass; dmarc=pass action=none; dkim=pass; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5lIIfyacRER35uaPRyY6e63u1alDCqcAh8nKDL5/cs8=; b=Pkeq0Pyzuby6c/6bz0fADC0BzJyL2+110YGwvNlXqEXhopBNT+1AQtEOJgFQfzAiUxF4JF+9D08OebOOPMEtjHRRPBMyb6SBFp2+7yGVMGZNDMY7ch6D4XUwPeuivMyc5hfDY4L2mKW7b2BiYcUAXJfYclzFsz8jlRTsE51Z71QwZZQqfOfz2rZuSOy1NI3IbLlejIMKNpIPV4EArySwKMwUpUa+HW5d5WXYfwffWJ6AZARn+dbrSib3FGQMKrfBa/pKoco71vUeF2efRtRpVwkggY7uUJDd3osAoASTVAfdKAlKmWf1HYdQ7FHPthm6PYzBKB92g18HO9Ui9sb5xQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=BwIqa2BQTtcOidaC/OG5FC3RfDaFmGaH3loxOzj3+zwWB4epfMRzUnHWVI24chdRzHhoJJjozrDfHiPBmdWj0BLeWkfpaKDSDL87SQqLA68p/a47xAKa15qsbfwGPmAVTyfME3AqyLkFEexsVqJRiMEBfv1Wx/km7OK6NaVAvgy6zwxgOqj8haV3rlzorAmuDHZMoQ/3O0YL4s8ruu7pXHPSmTkCJH3dFoXDbVpitLRZR9NSaihHRUIz8B6zlkRIUOTqFSGAVrTmk18ChLha9HNbR2IMNbWqq1moNZvEYBkH4J+J8PzekJ3YN/53HtR6kU819im0dDC0C+oWbdMjdg==



I know almost nothing about Openshift..... so... YMMV...


However for Docker... the following is NOT true at all.


> I think that is a general problem with openshift since i cannot

> guarantee any user at all. Instead openshift will generate a random GUID

> each run.



This is where the conversation gets hard....



Docker can "run as any OS user", or run as any "UID" (that exists on the OS or not) because it runs as root on the OS.


It ALSO has an "OPTIONAL feature" called "user namespaces". ( )

  However, user namespaces are "an advanced feature and require coordination with other capabilities".

  IF you use that feature then there is a "starting UID" and a "range of UID's" that can be used. ( Same for GUID's too.)

   And you may break other features of Docker too.



And all of that really should ONLY(?) matter ( as far as I can tell ) if you mount host directories/files into the container.
  because in the "user namespaces" model the stuff in the container is "foo" and it is mapped to stuff outside the container as "bar".

   The UID outside the container starts at a point in the "range of UIDs" that is configured. BUT inside they start at "zero" and "use more ID's from the range" as needed too.



If the outside range is 10000-50000.

The first container's "zero" UID is mapped to 10000, and its "753" UID is mapped to "10753", etc..., etc... ( or it just maps them serially without skipping... not sure, but you get the idea...)


I think the container process keeps track of what UID's in the range are used and will not allow the next container to "reuse them". (<--!!!   I am guessing a "high water mark approach")

   So the second container comes along and "zero" UID is mapped to 10754 (The next unused id left in the range?), and its "750" UID is mapped to "11504", etc...



If you don't use namespaces, then you can still run as a specific UID ( via the "docker run ... -user= <name|uid>[:<group|gid>]" and or --group-add=<list of groups to add to the user> ). Which is what I am doing.

Yes I also build an image and adjust the UID for all files in the contain to match the value I want. ( But that is because I am mounting stuff into the container too.)


And if you do use namespaces you can still force add a --group-add=<list of groups to add to the user> Because Group's could be mapped to a single value too. 😊




A quick google found

And says:
"The user ID isn't actually entirely random, but is an assigned user ID which is unique to your project. In fact, your project is assigned a range of user IDs that applications can be run as."

( Sounds like "user namespaces" to me. )

I would think that you can ( and should imho ) create a real group on the host. Prep the image with that GroupID in your build process. Then use the openshift equiv of "--group-add=" to make it line up.

YMMV. Untested, just a guess....




In my docker file I  do this...

RUN /usr/local/bin/ tomcat <UID_I_WANT_TO_USE> .... \

&& chown -R tomcat:tomcat  <lots of dirs....> 


Interestingly not /home/tomcat... so ... maybe I need to go check my logs better and see if that error is in there too. 😊



And for all I know... Darren has the "Real answer" .  ( Shrug. )





Carey Matthew


-----Original Message-----
From: <> On Behalf Of Darren Boss
Sent: Friday, May 29, 2020 3:46 PM
To: Oliver Trieu <>
Subject: Re: [grouper-users] Grouper 2.5 on Openshift


Could it be the underscores in headers issue?


If you are using an nginx ingress controller in OpenShift, make sure

you have the enable-underscores-in-headers: "true" setting set in the

nginx-configuration configmap.


On Fri, May 29, 2020 at 1:41 PM Oliver Trieu <> wrote:

> Hi Carey,

> Thank you very much for your fast reply!

> I gave 2.5.28 (and 2.5.29) a go.

> Using GROUPER_RUN_TOMCAT_NOT_SUPERVISOR=true will result in an error

> complaining that /home/tomcat/.bashrc is missing.

> I think that is a general problem with openshift since i cannot

> guarantee any user at all. Instead openshift will generate a random GUID

> each run.

> So permissions are handled via groups (thats why you see the strange

> permission handling in my dockerfile).

> So there is no way for me to guarantee the user tomcat (or any user).

> Anyway i just went ahead an started TomEE manually.

> This worked and the UI is no longer presenting the NullPointerException.

> However once i actually click something in the UI i run into CSRF errors:

> ERROR CsrfGuardLogger.log(47) -  - potential cross-site request forgery

> (CSRF) attack thwarted (user:oliver,  method:POST,

> uri:/grouper/grouperUi/app/UiV2Stem.viewStem, error:request token does

> not match session token)

> I should mention that we dont use the apache or shib implementation

> inside the container.

> We have a speperate container running apache and handling the shibboleth

> login for us.

> This setup has worked very well for us with grouper 2.4.

> If i look at the Client side i can see my Post requests only partly

> containing a CSRF token.

> Request URLs in the CLient:



> TomEE access-log:


> /grouper/grouperUi/app/UiV2Stem.viewStem?stemId=1aa6aa124e7846e294b98fcf559a9a32&csrfExtraParam=xyz

> HTTP/1.1" 302 -


> /grouper/grouperExternal/public/UiV2Public.postIndex?function=UiV2Public.error&code=csrf&OWASP_CSRFTOKEN=BMAH-0KYJ-ZNY2-50TB-M1S6-XDUG-I7ZC-2JJO

> HTTP/1.1" 200 4051

> So the viewStem request is missing the Token and triggers the Error.

> Any ideas what the problem could be?

> Kind Regards

> Oliver

> Am 29.05.2020 um 16:30 schrieb Black, Carey M.:

> > REF:

> >*container*documentation*for*v2.5__;KysrKw!!KGKeukY!g7Fle1p02e1vGsbxv70xmfBsVPb4O8pWspkBVvtCwoG8jaKD9RR9QieMhS9TcIXF0zI$

> > "


> > (v2.5.28+)

> >

> > Will run the tomee process as the only process in the container, not

> > supervisor. Note, this is advanced, and should be run as the tomcat user.

> > See this wiki

> > "

> >

> > Try on a later image. I think v2.5.28+ will do what you want.

> >





Darren Boss

Senior Programmer/Analyst

Programmeur-analyste principal

Archive powered by MHonArc 2.6.19.

Top of Page