Write access to /home required for functions tooling to create /home/.azurefunctions folder

[ggirard07]

I have a solution configured with .dcproj and docker-compose I use for debugging purposes. I am now trying to add a function app project to the same solution.

Currently, when running in a non-root variant of the dotnet isolated function image, the folder /home/.azurefunctions needs to be pre-created before trying to start a debug session.
If folder does not exist yet, tooling tries to create it as the non-root user but does not have permission to /home by default. It results result in a permission denied error and fast mode fails to start the image.
My workaround for now is to create the folder in my own base image.

Looking at the content of the folder, I am not sure I understand its purpose at it always empty.

[NCarlsonMSFT]

@ggirard07 I'm not finding examples for the "non-root variant of the dotnet isolated function image". Could you point me to an example?

[ggirard07]

@ggirard07 I'm not finding examples for the "non-root variant of the dotnet isolated function image". Could you point me to an example?

I did that one myself as I assume it will be provided by the functions team when they officially support dotnet 8. But I had to do it now, as running rootless is a requirement for our clusters.

FROM mcr.microsoft.com/azure-functions/dotnet-isolated:4-dotnet-isolated6.0

# workaround for Visual Studio debug trying to create this folder as non-root user
RUN mkdir /home/.azurefunctions

# Non root user based on upcoming dotnet 8 (https://github.com/dotnet/dotnet-docker/blob/5be37f32707bd3f0ff7605a71406c37e68975947/src/runtime-deps/8.0/jammy/amd64/Dockerfile)
# Except for group/user names as Docker tooling for Visual Studio seems to not enforce DockerFastModeProjectMountDirectory
RUN groupadd \
        --gid 1654 \
        site \
    && useradd -l \
        --uid 1654 \
        --gid site \
        --create-home \
        site
RUN chown site:site /home/.azurefunctions

ENV ASPNETCORE_URLS=http://+:8080 \
    AzureWebJobsScriptRoot=/home/site/wwwroot 

USER site

Note that I also have a separate issue using the same username as upcoming dotnet 8 (app instead of site), as this result in functions required to be mounted to non-default location /home/app/wwwroot instead of /home/site/wwwroot. But current tooling always mounts the file to default /home/site/wwwroot, regardless of env variable AzureWebJobsScriptRoot or DockerFastModeProjectMountDirectory. But since I am sharing my Dockerfile 😅

[NCarlsonMSFT]

@ggirard07 The error you're seeing isn't coming from the VS tools, but instead the Azure Functions CLI, specifically: https://github.com/Azure/azure-functions-core-tools/blob/v4.x/src/Azure.Functions.Cli/Common/PersistentSettings.cs

Digging through the history of the mcr.microsoft.com/azure-functions/dotnet-isolated:4-dotnet-isolated6.0 image it appears that $HOME is being set to /home. updating my Dockerfile to use

ENV HOME=/home/app

let me set-up a low privileged app user like the one used in the .NET 8 images. This however seems wrong, and I think a conversation is needed with the owners of the Azure Functions image.

[ggirard07]

@NCarlsonMSFT Thanks for digging into that. It looks like your repo get a lot of false-positive feedback due to issues in tooling you are interacting with, sorry about the noise 😅
I also noticed the misconfiguration for $HOME when dealing with user secrets, but I also reported it in your repo (#398) as I was not sure if DockerTools should honor the $HOME configuration regardless if it made sense.

[NCarlsonMSFT]

@ggirard07 The user secrets in Azure Functions issue is next on my to-do list. As of now, the compose tooling doesn't support User Secrets for Azure Functions which is what needs to be addressed first. The support for the non-root user on Azure Functions is a separate issue that seems like it will need some coordination with the Azure Functions team.

[dbreshears]

Closing stale issue, workaround available.