`kubectl cp` relies on tar to extract the copied file/directory in the
container, tar by default attempts to chown/chmod the extracted file
after extraction if the user is the "superuser"(root)
```
--same-owner
try extracting files with the same ownership as exists in the archive
(default for superuser)
-p, --preserve-permissions, --same-permissions
extract information about file permissions (default for superuser)
```
This fails in environment where the container runs as root but is not
granted the OWNER or CHOWN capability.
Before this patch below was the behavior of `kubectl cp`
```
kubectl cp README.md foo-67b6fcbd4c-qjlt6:/tmp
tar: README.md: Cannot change ownership to uid 1000, gid 1000: Operation
not permitted
tar: Exiting with failure status due to previous errors
command terminated with exit code 2
kubectl exec -it foo-67b6fcbd4c-qjlt6 -- ls -l /tmp/README.md
-rw------- 1 1000 1000 3179 Oct 7 22:00 /tmp/README.md
```
After this patch
```
kubectl cp -x a foo-67b6fcbd4c-qjlt6:/
kubectl exec -it foo-67b6fcbd4c-qjlt6 -- ls -l /tmp/README.md
-rw-r--r-- 1 root root 3179 Oct 7 22:00 /tmp/README.md
```
The dependency on printers/internalversion was causing kubectl/scheme
to have defaulters registered, which should not be the case. Remove
defaults from the test.
The types referenced in credentialprovider are part of a long term api
and will not change, and kubectl doesn't need to take a dependency on this
package in order to do minimal validation here.
pkg/kubectl has a lot of files. Move everything generator related
into pkg/kubectl/generate (generic) or pkg/kubectl/generate/versioned
(type specific).
Move the DescriberFn and GeneratorFn out of kubectl/cmd/util and into
the respective versioned packages, along with tests.
Adds an extra check condition for "." in stripPathShortcuts
so that an empty string is returned, and the correct prefix
index is used untarAll when generating path names.
Resolves: #69804.
We changed the code to verify that the type supports dry-run, but we've
only done it for patch, not for create, which means that people can
create objects they don't want to create. We can actually simplify the
code by moving the check much earlier in the method, which fixes all
possible bug like this.
For each object, first we verify if they have a dryRun parameter in the
openapi for the patch verb. If we can't find the object, we assume that
CRD will behave like "namespace". So we check if namespace supports
dryRun. If it does, then we verify that the resource is a CRD.
We don't want to run dryRun requests against servers that don't support
dry-run, since they might ignore the flag and just persist the unwanted
changes.
This creates a new method that checks in the OpenAPI if the dryRun
parameter can be used.
