-
Notifications
You must be signed in to change notification settings - Fork 97
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
Ownership not preserved in resulting tarball #1395
Comments
So, I've been curious about the root cause and spent some time analysing this myself, and came to the conclusion that the root cause is more on the apko side, but there are multiple reasons why this is failing as of today. I first started to analyze the situation when melange builds a tarball:
I was able to get everything working correctly on apko's side by:
You can find both of these changes in my forked apko branch Once apko has been extended with the above two commits, melange itself can be adjusted to use the gRPC FUSE ownership option based on its environment, as seen on the I did not implement any heuristics / detection for this yet, as it's simply meant as a PoC, but I suppose it could be based on the runner environment - e.g. if Docker is used on macOS, then use gRPC FUSE based permissions. With these changes to both apko and melange I'm finally able to build both a clean APK tarball (preserving custom permissions, while not leaking host account UID/GID through) and a clean OCI image with proper permissions as well. Now my question: Would changes like these be acceptable to the melange/apko team? Or has this not been implemented on purpose so far for some reason unknown to me? |
I've also tested this out on a Linux system by now, to have the full picture in terms of ownership support. Here is a summarised breakdown of everything:
The question that remains on my side is why apko does not preserve ownership (implementation is trivial, as shown in my previous comment with ppmathis/apko@dd8c452) and instead forces 0:0. The melange bug on macOS makes sense, it's a special case, but why would apko ignore ownership? |
If I had to guess, it's not deliberate, just an oversight. Since Feel free to PR that change to apko. It would be good to have a test that checks this and ensures it's consistent with |
This is probably somewhat related to the fixed and closed #501, but in my own attempts to use melange + apko together it was impossible for me to build a package with melange where certain paths have custom ownership. Based on my current understanding, the issue should be within melange and apko is not to blame, but just to be sure, I included a full example as a reproducer.
My first attempt was running the latest Podman Desktop release on macOS 14.5 (MacBook Pro M1), but there I was not even able to use
chown
within the melange pipeline. While the commands ran successfully, the changes have not even been persisted within the sameruns
step, meaning thatchown
followed byls
(as done in[1]
and[2]
in the reproducer) was never showing any changes. I think the file system used during builds was somehow not able to work together with Podman, so I put the blame on the differences to Docker, especially since I do not currently have a deep understanding of the Melange build process.My second attempt, after removing Podman completely from the system, was to instead use Docker Desktop. Here the initial attempt looked way more promising, as running
ls
afterchown
orchmod
now properly shows the changes, both for[1]
and[2]
in the melange reproducer config.Unfortunately, the changed ownership is not being reflected in the final output of the melange tar archive. I read through the previously linked issue and saw the adjusted tarball emitter for the data archive, so I would have assumed that
tar --list --numeric-owner -tf packages/aarch64/ownership-1.0.0-r0.apk
will show the proper UIDs/GIDs, except for the build user with1000:1000
, which should be remapped to UID/GID0:0
, but I get this output instead:The UID/GID combination of
501:20
matches the UID/GID on my MacOS host system, where this happens to be the primary and active user. If I install this package using apko for building a container image from it, all ownership information seems lost:I also double-checked the tar archive from apko with
dive
, but had the same findings - there is simply no ownership information present on these files anymore, but the permissions were kept.Based on my understanding, I would consider this a bug and it does not match my own expected behaviour. While I can use
paths
in apko, it seems like a bad practice to do so, as these paths are concerned to the package itself, and when e.g. combining multiple packages as a service-bundle in apko, I do not want to repeat package-specific path configs across multiple files.Version Info
melange
apko
Docker
Reproducer
Steps
melange keygen
melange build --signing-key melange.rsa
apko build -k melange.rsa.pub apko.yaml ownership ownership.tar
docker load < ownership.tar
docker run -it --rm ownership:latest-arm64 ls -lan /ownership
dive --source docker-archive ownership.tar
While the permission changes with
chmod
are respected, the ownership changes are lost, and both/ownership/file
as well as/ownership/dir
show up as being owned by root.melange.yaml
apko.yaml
The text was updated successfully, but these errors were encountered: