-
Notifications
You must be signed in to change notification settings - Fork 90
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Untar does not support symbolic links #538
Comments
Hi, thanks for reporting the issue. I did some inspection of the artifact you've used above and my conclusion is that it's not the type of OCI artifact that flux expects. The image contains full linux root filesystem of debian buster/sid. Regarding handling of symlinks, after digging into the history of the untar package, it looks like it was copied from upstream golang project and that was copied from another internal package which was for their specific use case, which didn't account for symlinks. In case of flux, I don't think there would be common use cases for symlinking manifests or other files in an artifact, but because our OCI support is more like a universal artifact format, I think it'd be good to add symlink handling as well. |
That's fair, thanks for the response. Yes it might be a good idea to actually use the upstream Golang library instead of using this copy+paste. |
Sounds like some misunderstanding. The upstream code isn't public, refer Line 6 in 2e870a1
And I meant that in the upstream's context, they may not need to care about symlinks but in our context, we may. So, we can diverge from the upstream and add symlink support. |
I am seeing the same issue while extracting image layer with symlink
|
I'm seeing the same error as well. It appears that even though Docker images are OCI compliant there are problems. https://www.docker.com/blog/demystifying-open-container-initiative-oci-specifications/ |
We never said we support Docker images, we made a conscious decision to reject OCI artifacts with symbolic links and other non-standard file types. @djschny I see you work at VMware, so please sync up with your peer @rashedkvm, we've discuss this topic in detail on Flux dev meetings several times. |
@djschny as @stefanprodan mentioned we discussed in the last Flux community meeting and decided to reject the sym-link when untaring image layer(s). If you'd like to talk more hit me up on Slack. |
It's OK, I can replace flux with a 4 line shell script in CronJob and be way more flexible. |
Summary
When creating an
OCIRepository
to monitor the following docker repo: https://artifacthub.io/packages/helm/kiwigrid/spring-cloud-config-server, I get an error sayingfailed to extract layer contents from artifact: tar file entry bin/bzcmp contained unsupported file type Lrwxrwxrwx
.The errors at
loglevel=debug
are:Potential cause
This case statement seems to be the culprit because it does not support
FileMode.ModeSymlink
.pkg/tar/tar.go
Lines 112 to 174 in a39c961
Is this intentional?
Steps to Reproduce:
flux create source oci sck-config-server \ --namespace sck-config-server \ --url oci://docker.io/springcloud/spring-cloud-kubernetes-configserver \ --tag 3.0.3-SNAPSHOT
Versions
flux CLI version
0.41.2
Container versions:
image: docker.io/fluxcd/helm-controller:v0.31.2
image: docker.io/fluxcd/kustomize-controller:v0.35.1
image: docker.io/fluxcd/notification-controller:v0.33.0
image: docker.io/fluxcd/source-controller:v0.36.1
The text was updated successfully, but these errors were encountered: