Question: Container file system permissions

[morremeyer]

Hey everyone!

For https://github.com/envelope-zero/backend, we recently started using goreleaser with ko to build the image for multiple architectures. We currently use the default image, cgr.dev/chainguard/static to get the benefit of running rootless.

The Envelope Zero backend uses an sqlite database that is at data/gorm.db relative to the binary.

For some environments, this works great, e.g. kubernetes, where users mount a volume with the correct permissions for the nonroot user.

For other environments however, this does not work. For example in docker-compose and GitHub actions service containers, we cannot set the owner of a volume mount directory.

The default way for a docker build would be to create the needed data directory and chown it in the Dockerfile.
However, since ko does not use a Dockerfile, that is not possible.

Is there any guidance for how to solve this neatly, preferably without maintaining our own base image?
Thanks in advance for any ideas or feedback you might have!

[ipince]

This also seems to be a problem when deploying images onto Google Cloud Run. Using GCP's default image (i.e. building from source with gcloud run deploy --source .) gives you read/write access to the (ephemeral) filesystem, while using ko's default seems to only give readonly access.

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Keep fresh with the 'lifecycle/frozen' label.

[morremeyer]

still an issue

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Keep fresh with the 'lifecycle/frozen' label.

[morremeyer]

still an issue

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Keep fresh with the 'lifecycle/frozen' label.

[morremeyer]

This is still an issue, please reopen.

[imjasonh]

Hey, sorry for letting this slip so long. Let's see if we can figure out what's going on.

Using GCP's default image (i.e. building from source with gcloud run deploy --source .) gives you read/write access to the (ephemeral) filesystem, while using ko's default seems to only give readonly access.

I'm definitely not able to reproduce this. I use ko with Cloud Run very heavily, and have never had an issue writing to the ephemeral disk. Do you have a simple repro case that fails, that I could use to investigate?