[Feat]: Add ability to set umask (from environment variable)

[csjewell]

Is your feature request related to a problem? Please describe.

I'm currently encountering frustration trying to bring zot up on OpenShift Local on my laptop due to permissions issues.

Specifically, I'm trying to get it to run while pulling the registry out to a directory within my home directory so it can be persistent between instantiations of the virtual machine.

The problem is that OpenShift Local is "opinionated" in what it runs its users under. I've tried both precreating the directory the registry is to be put in with 777 (or even 2777) permissions, and allowing OpenShift to do so. In the first case, when I try to push a docker image, I get an error (will recreate it in just a bit to put as a comment.) In the second case, zot will not even start (because it can't write the index.db)

(I'm reporting to you, but I know enough go that I'll try to send you a PR this weekend if you don't get to it before then. My understanding is that it should be a single-digit number of lines as far as the go code that is compiled to the zot binary is concerned - the question I haven't looked at yet is where to put said lines. You'll also see some Helm chart improvements from me in a few days.)

I'll come back after I sanitize zot's logs (just the URL's being hit, I promise) and attach those as well.

docker-output.txt
kubectl-neat-output.txt
ls-output.txt

Describe the solution you'd like

I'd like the ability to get the files group-read/writable - and being able to set the umask to 002 might help with that.

Describe alternatives you've considered

No response

Additional context

No response

[csjewell]

And it turns out zot is returning a 415 because docker is sending its manifest with the "application/vnd.docker.distribution.manifest.v2+json" content-type and OCI-style doesn't like that! The permissions aren't the cause of the problem I'm having. Still, I see myself needing the group-writability for another reason: OpenShift sets a retrievable-but-different UID, so the persistence would still need a way to change the file ownership otherwise. But lower-priority than it was.

[rchincha]

@csjewell #724

[csjewell]

Thank you, @rchincha ... That explains better why my original problem is occurring, and I understand that it's a tough thing to ask. Maybe we can mention why the error occurs better on zotregistry.dev.

That being said, I was having TWO problems and #724 would have only solved one of them. I did mention I'm still having a problem where I cannot really do persistence because the permissions aren't right in K8s environments based on OpenShift - right now I have to do persistentVolumeReclaimPolicy: Recycle in my PersistentVolume manifest where I'd really like to use Retain, instead) - what the solution may be is to create a Wolfi-based (or gcr-distroless-based, that could be chooseable) image that contains zot and a small Go re-runner in front of it as described in GoogleContainerTools/distroless#1217. I'll put the code that builds that image up when I'm done.

[csjewell]

(I do note that it looks like there's already a Wolfi image described at https://images.chainguard.dev/directory/image/zot/versions - I'll double-check it first and see if it solves the problem already.)