What should we do when the chiseled image does not have the necessary permissions in an external volume?

[64J0]

I'm currently facing a problem where the application container must have access to an external volume. It needs to have both read and write permissions for the application to work properly.

When this application tries to check the volume, it throws an error related to the lack of permissions.

How should we handle this, considering the .NET chiseled best practices?

I was considering to change the permissions of the volume folder, but I'm unsure if this is the right path to follow. My main concern is related to the trust in the non-root user of the chiseled image. I was trying to get its information by using the id command, but this tool is not available in the chiseled image.

If you guys can share how can I consult the UID and GID of the non-root user of a chiseled image, that would be cool as well.

[64J0]

There's a way to get the user by inspecting the container. One can use this command:

# for example this tag jammy-chiseled:
docker pull mcr.microsoft.com/dotnet/nightly/aspnet:6.0-jammy-chiseled
docker image inspect mcr.microsoft.com/dotnet/nightly/aspnet:6.0-jammy-chiseled

There we can check the user (ID):

Can we trust that this UID is going to be used in next versions?

[richlander]

We plan to never change this UID (or name).

[richlander]

Typically, the mount needs to give permissions to this specific user.

[richlander]

BTW: We should write guidance on this. Feel free to file an issue requesting that.

[64J0]

Cool, created it here: #4778

[64J0]

I'm considering this hacky workaround: https://pratikpc.medium.com/use-docker-compose-named-volumes-as-non-root-within-your-containers-1911eb30f731

[jander-msft]

A possible option, if you are using Kubernetes, is to specify a security context with the fsGroup property: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-the-security-context-for-a-pod

This will allow the container processes within the pod to have a supplemental group identifier (whichever value you specified) and the group owner of the volume will be changed to that same identifier. This would possibly allow you to not have to interrogate/change the uid of any container processes or files on the volume.

[64J0]

I'll keep this in mind, thanks for the reply @jander-msft. I'm currently trying to solve this problem for local docker-compose.yml only, but the next step is going to be using a Kubernetes local emulator (minikube probably).