<p dir="auto"><strong>Is this a request for help?</strong> (If yes, you should use our troubleshooting guide and community support channels, see <a href="http://kubernetes.io/docs/troubleshooting/" rel="nofollow">http://kubernetes.io/docs/troubleshooting/</a>.): No</p>
<p dir="auto"><strong>What keywords did you search in Kubernetes issues before filing this one?</strong> (If you have found any duplicates, you should instead reply there.): "tarball", "permissions"</p>
<hr>
<p dir="auto"><strong>Is this a BUG REPORT or FEATURE REQUEST?</strong> (choose one):</p>

<p dir="auto"><strong>Kubernetes version</strong> (use <code class="notranslate">kubectl version</code>): 1.3.8</p>
<p dir="auto"><strong>Environment</strong>:</p>
<ul dir="auto">
<li><strong>Cloud provider or hardware configuration</strong>: bare metal</li>
<li><strong>OS</strong> (e.g. from /etc/os-release): Debian</li>
<li><strong>Kernel</strong> (e.g. <code class="notranslate">uname -a</code>): n/a</li>
<li><strong>Install tools</strong>: none – custom repackaging</li>
<li><strong>Others</strong>:</li>
</ul>
<p dir="auto"><strong>What happened</strong>:</p>
<p dir="auto">Starting with version 1.3.8, the permissions of all the files in the release tarball (both direct and in the inner tarballs) have changed from 755 to 750 or 644 to 640, resp. I pulled and looked at the permissions of the inner tarballs over a few versions, see <a href="https://gist.github.com/matthiasr/1066cbb833e197592ee515faa0a782fd">this gist</a>.</p>
<p dir="auto"><strong>What you expected to happen</strong>:</p>
<p dir="auto">Files to have stable permissions across versions.</p>
<p dir="auto"><strong>How to reproduce it</strong> (as minimally and precisely as possible):</p>
<p dir="auto">As root, unpack <code class="notranslate">kubernetes.tar.gz</code>. As non-root, try to use any of the binaries.</p>
<p dir="auto"><strong>Anything else do we need to know</strong>:</p>
<p dir="auto">I came across this because we blindly carried the permissions over into our custom repackaging. We do that now, so it's not urgent for us to change anything but it was confusing at first (especially in a patch upgrade). I also don't think there is any reason for this change?</p>
<p dir="auto"><strong>Is this a request for help?</strong> (If yes, you should use our troubleshooting guide and community support channels, see <a href="http://kubernetes.io/docs/troubleshooting/" rel="nofollow">http://kubernetes.io/docs/troubleshooting/</a>.): no</p>
<p dir="auto"><strong>What keywords did you search in Kubernetes issues before filing this one?</strong> (If you have found any duplicates, you should instead reply there.): kubectl, get, export, --export, flag</p>
<hr>
<p dir="auto"><strong>Is this a BUG REPORT or FEATURE REQUEST?</strong> (choose one): BUG REPORT</p>

<p dir="auto"><strong>Kubernetes version</strong> (use <code class="notranslate">kubectl version</code>):</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="λ kubectl version
Client Version: version.Info{Major:&quot;1&quot;, Minor:&quot;3&quot;, GitVersion:&quot;v1.3.7&quot;, GitCommit:&quot;a2cba278cba1f6881bb0a7704d9cac6fca6ed435&quot;, GitTreeState:&quot;clean&quot;, BuildDate:&quot;2016-09-12T23:15:30Z&quot;, GoVersion:&quot;go1.6.2&quot;, Compiler:&quot;gc&quot;, Platform:&quot;darwin/amd64&quot;}
Server Version: version.Info{Major:&quot;1&quot;, Minor:&quot;3&quot;, GitVersion:&quot;v1.3.6&quot;, GitCommit:&quot;ae4550cc9c89a593bcda6678df201db1b208133b&quot;, GitTreeState:&quot;clean&quot;, BuildDate:&quot;2016-08-26T18:06:06Z&quot;, GoVersion:&quot;go1.6.2&quot;, Compiler:&quot;gc&quot;, Platform:&quot;linux/amd64&quot;}"><pre class="notranslate"><code class="notranslate">λ kubectl version
Client Version: version.Info{Major:"1", Minor:"3", GitVersion:"v1.3.7", GitCommit:"a2cba278cba1f6881bb0a7704d9cac6fca6ed435", GitTreeState:"clean", BuildDate:"2016-09-12T23:15:30Z", GoVersion:"go1.6.2", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"3", GitVersion:"v1.3.6", GitCommit:"ae4550cc9c89a593bcda6678df201db1b208133b", GitTreeState:"clean", BuildDate:"2016-08-26T18:06:06Z", GoVersion:"go1.6.2", Compiler:"gc", Platform:"linux/amd64"}
</code></pre></div>
<p dir="auto"><strong>Environment</strong>:</p>
<ul dir="auto">
<li><strong>Cloud provider or hardware configuration</strong>: GKE</li>
<li><strong>OS</strong> (e.g. from /etc/os-release): OS X 10.11.6</li>
<li><strong>Kernel</strong> (e.g. <code class="notranslate">uname -a</code>): Darwin ... 15.6.0 Darwin Kernel Version 15.6.0: Thu Jun 23 18:25:34 PDT 2016; root:xnu-3248.60.10~1/RELEASE_X86_64 x86_64</li>
<li><strong>Install tools</strong>: gcloud</li>
<li><strong>Others</strong>:</li>
</ul>
<p dir="auto"><strong>What happened</strong>:<br>
<code class="notranslate">kubectl get --export</code> doesn't strip the cluster specific info from resources (self-links, etc.)</p>
<p dir="auto"><strong>What you expected to happen</strong>:<br>
<code class="notranslate">kubectl get --export</code> should provide a cluster-unspecific resource that can be redeployed right away</p>
<p dir="auto"><strong>How to reproduce it</strong> (as minimally and precisely as possible):</p>
<p dir="auto"><strong>Anything else do we need to know</strong>:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="temikus λ kubectl get deployments --export -o=yaml &gt; deploy.yaml
temikus λ kubectl get deployments -o=yaml &gt; deploy_false.yaml
temikus λ diff deploy*
##empty line, should actually be a diff"><pre class="notranslate"><code class="notranslate">temikus λ kubectl get deployments --export -o=yaml &gt; deploy.yaml
temikus λ kubectl get deployments -o=yaml &gt; deploy_false.yaml
temikus λ diff deploy*
##empty line, should actually be a diff
</code></pre></div>