Bug 1316747 - Umask affecting S2I build results
Umask affecting S2I build results
Status: VERIFIED
Product: OpenShift Container Platform
Classification: Red Hat
Component: Fuse (Show other bugs)
3.0.0
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: Roland Huss
David Simansky
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-03-10 20:41 EST by Qi Yong
Modified: 2017-06-19 06:34 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
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)
pom.xml (9.12 KB, application/xml)
2016-03-17 21:33 EDT, Qi Yong
no flags Details

  None (edit)
Description Qi Yong 2016-03-10 20:41:19 EST
Description of problem:
When build a maven deployment; the host has a umask of:

0077
fabric8 build process creates the tarball with 700 which is unusable in the pod as the pod was run with an arbitrary UID.

Version-Release number of selected component (if applicable):


How reproducible:
This problem occurs when following the documentation at this link (https://docs.openshift.com/enterprise/latest/using_images/xpaas_images/fuse.html) for working with the Fuse XPaas image. The archetype that we picked to build was the "karaf-camel-log-archetype". We followed the steps to create the application from the maven archetype catalog which are summarized below:

Steps to Reproduce:
1. $ oc new-project fabric8
2. $ export KUBERNETES_MASTER=https://cloudapps.com:8443
3. $ export KUBERNETES_DOMAIN=cloudapps.com
4. $ mvn -Pf8-deploy -Ddocker.registry=registry.cloudapps.com:443 -Ddocker.username='test' -Ddocker.password=test -D docker.host=http://localhost:2375

Actual results:
The image when run as an arbitrary fails due to a permission problem (see below).

Checking for *.tar.gz in /deployments
tar (child): /deployments/ose-fuse-example-1.0-SNAPSHOT.tar.gz: Cannot open: Permission denied
tar (child): Error is not recoverable: exiting now
tar: Child returned status 2
tar: Error is not recoverable: exiting now
sed: can't read /deployments/karaf/etc/org.ops4j.pax.logging.cfg: No such file or directory
Executing /deployments/karaf/bin/karaf server ...
/usr/local/s2i/run: line 16: /deployments/karaf/bin/karaf: No such file or directory

Expected results:
* the Maven job should check what the umask setting is
or
* if Maven creates a tarball that has 0700 permissions, it should change it to something that would be usable by ANY UID - perhaps it should default to setting a usable permission regardless.
Additional info:
The workaround is to do a "umask 0022"  so that the arbitrary user running the image has access to the tar file.
Comment 1 Roland Huss 2016-03-16 03:26:22 EDT
Which version of the archetype did you use ? (2.2.0.redhat-621030 ?)
Comment 2 Roland Huss 2016-03-16 04:21:14 EDT
Currently I'm struggling with downloading the proper archetype, the one I get following the referenced documentation doesn't look up-to-date to the latest release. Would be good if I would know the exact version of the archetype used so that I can reproduce it.

btw, the build flow used here doesn't involve s2i at all, the only s2i relevance is that a hybrid base image is used. So the subject of this issue might be a bit misleading.
Comment 3 Qi Yong 2016-03-16 21:35:22 EDT
(In reply to Roland Huss from comment #2)
> Currently I'm struggling with downloading the proper archetype, the one I
> get following the referenced documentation doesn't look up-to-date to the
> latest release. Would be good if I would know the exact version of the
> archetype used so that I can reproduce it.
> 
> btw, the build flow used here doesn't involve s2i at all, the only s2i
> relevance is that a hybrid base image is used. So the subject of this issue
> might be a bit misleading.

Please find following response from customer and let me know if other info are needed, thanks:

I didn't make a note of exactly which version was used, but it was either 2.2.0.redhat-079 or 2.2.0.redhat-621030.
Comment 4 Roland Huss 2016-03-17 02:41:41 EDT
ok,  must be 2.2.0.redhat-079 since 2.2.0.redhat-621030 doesnt contain any profiles. I wonder, how this repo could be cleaned up a bit ?
Comment 5 Roland Huss 2016-03-17 02:51:01 EDT
Sorry, I'm still struggling in reproducing it. When using the 2.2.0.redhat-079 archetype, the it refers to a none existing base image 'jboss-fuse-6/fis-karaf-openshift:1.0'. I don't think thats the final archetype version.

Could you please post the pom.xml which you used ?
Comment 6 Qi Yong 2016-03-17 21:33 EDT
Created attachment 1137641 [details]
pom.xml
Comment 7 Qi Yong 2016-03-17 21:34:29 EDT
Please find (In reply to Roland Huss from comment #5)
> Sorry, I'm still struggling in reproducing it. When using the
> 2.2.0.redhat-079 archetype, the it refers to a none existing base image
> 'jboss-fuse-6/fis-karaf-openshift:1.0'. I don't think thats the final
> archetype version.
> 
> Could you please post the pom.xml which you used ?

Please find pom.xml attached. Thanks.
Comment 8 Roland Huss 2016-03-18 09:36:53 EDT
Thanks. According to the pom.xml its 2.2.0.redhat-079

I tried to reproduce the issue, however it seems to work for me.

Here is how the /deployment directory looks like when the Pod is running:

sh-4.2$ ls -l .
total 20976
drwxr-xr-x. 8 1000040000 root        87 Mar 18 09:26 demo-1.0-SNAPSHOT
-rw-r--r--. 1 jboss      jboss 21474006 Mar 18 09:24 demo-1.0-SNAPSHOT.tar.gz
-rwxrwxrwx. 1 jboss      jboss      724 Mar  1 03:36 deploy-and-run.sh
lrwxrwxrwx. 1 1000040000 root        30 Mar 18 09:25 karaf -> /deployments/demo-1.0-SNAPSHOT
sh-4.2$

so here the tar archive is 644. How does it look like for you ? Also, in the build could you please do a 

   ls -lR target/docker/| grep \\.tar

and post the output ?

What umask do you have before calling Maven ? 

When I deliberately set this to `umask 0777` then I can't even build, so I wonder how this non-readable tar.gz could happen for you. 

Last question: On which platform are you building (Linux / OSX / Windows) ?
Comment 9 Roland Huss 2016-03-22 02:45:15 EDT
Could you please help me ? I really can't reproduce it here. The "/deployment" directory has deliberately 777 as permission so extracting should (and is not) a problem.

If you are running on Windows, could you please try to insert a `<mode>tar</mode>` in the `<assembly>...</assembly>` section in the pom.xml ?

thanks ...
... roland
Comment 11 Qi Yong 2016-03-23 21:30:50 EDT
(In reply to Roland Huss from comment #8)
> Thanks. According to the pom.xml its 2.2.0.redhat-079
> 
> I tried to reproduce the issue, however it seems to work for me.
> 
> Here is how the /deployment directory looks like when the Pod is running:
> 
> sh-4.2$ ls -l .
> total 20976
> drwxr-xr-x. 8 1000040000 root        87 Mar 18 09:26 demo-1.0-SNAPSHOT
> -rw-r--r--. 1 jboss      jboss 21474006 Mar 18 09:24 demo-1.0-SNAPSHOT.tar.gz
> -rwxrwxrwx. 1 jboss      jboss      724 Mar  1 03:36 deploy-and-run.sh
> lrwxrwxrwx. 1 1000040000 root        30 Mar 18 09:25 karaf ->
> /deployments/demo-1.0-SNAPSHOT
> sh-4.2$
> 
> so here the tar archive is 644. How does it look like for you ? Also, in the
> build could you please do a 
> 
>    ls -lR target/docker/| grep \\.tar
> 
> and post the output ?
> 
> What umask do you have before calling Maven ? 
> 
> When I deliberately set this to `umask 0777` then I can't even build, so I
> wonder how this non-readable tar.gz could happen for you. 
> 
> Last question: On which platform are you building (Linux / OSX / Windows) ?

The default umask is 0077.  Here the output with that umask

$ ls -lR target/docker/| grep \\.tar                                         
-rw-------. 1 buckm buckm 38917226 Mar 23 17:04 fuse-1.0-SNAPSHOT.tar.gz
-rw-------. 1 buckm buckm 38922240 Mar 23 17:05 docker-build.tar

And here's how it looks with umask 0022
$ ls -lR target/docker/| grep \\.tar
-rw-r--r--. 1 buckm buckm 38917228 Mar 22 15:23 fuse-1.0-SNAPSHOT.tar.gz
-rw-r--r--. 1 buckm buckm 38922240 Mar 22 15:23 docker-build.tar

You can see the difference, that it's world-readable only with the umask change.

I cannot show you  the permissions inside the running pod with the default umask because it terminates, but I think the issue is clear from what I've provided above.

Lastly, I'm running this on a RHEL7 linux VM.
Comment 12 Roland Huss 2016-03-29 11:56:28 EDT
Ok, got it.

The fix is simple and needs an adaption of the archetype. In the configuration section the fileMode needs to be set explicitely:

                  
<inline ...>
   <id>${project.artifactId}</id>
   <files>
      <file>                       
         <source>${project.build.directory}/${project.artifactId}-${project.version}.tar.gz</source>
         <fileMode>0644</fileMode>
         <outputDirectory>/</outputDirectory>
      </file>
   </files>
</inline>

I can fix this upstream but have no idea how this get into the product and which buttons needs to be pushed.

Any idea ?
Comment 13 Roland Huss 2016-03-29 12:17:29 EDT
BTW, only the Karaf based archetypes should be affected, the others already have the permission set explicitly.
Comment 14 Roland Huss 2016-03-29 13:42:04 EDT
The upstream fix is in this PR https://github.com/fabric8io/ipaas-quickstarts/pull/1191 (which will be applied tomorrow after some review)
Comment 15 Roland Huss 2016-04-04 02:10:18 EDT
Fix has been merged in both branches, redhat and master.

What are the next steps ?
Comment 21 Marek Schmidt 2017-06-19 06:34:35 EDT
Verified on Karaf FIS archetypes versions 2.2.0.redhat-085 

all declare <fileMode>0644</fileMode>

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