What directory is writable in an aspire container?

[LanceMcCarthy]

Hi folks,

I really need a way to write a simple text file in my ApiService container.

No matter what I try, it seems that after deployment to Azure the restricted 'app' user cant even create a txt file in its own directory, nor in the (usually globally-writable) /var/log directory.

Here's a screenshot the console of the aspire app in Azure. I try three times to test to see if I can write a text file:

That last one, /var/log , is typically a universal writable directory in Linux, but apparently not available to the app user.

Why?

It's nearly impossible to debug a Linux-only, production-only, problem that is precompiled (i.e. not in my code, so I cant determine where to send the diagnostics). However, he upstream library author does make sure this output is available via TraceListener for this exact reason.

So, here's what I'm using to try and get those traces:

var logFilePath = "_traceoutput.log";

// Experimenting with this, it's not always here
File.SetUnixFileMode(logFilePath, UnixFileMode.UserRead | UnixFileMode.UserWrite);

// I need this
System.Diagnostics.Trace.Listeners.Add(new System.Diagnostics.TextWriterTraceListener());
System.Diagnostics.Trace.AutoFlush = true;

If you have an alternate suggestion, say stream the traces somewhere else, I'm all-ears :)... but this no-root, and restricted app user is causing more problems right now.

[LanceMcCarthy]

I do see Seq https://learn.microsoft.com/en-us/dotnet/aspire/logging/seq-component?tabs=package-reference as a production-worthy option, so I'll post it here.

Though I am looking for a quick one-off instead of having to wire up an entire new service just for a one-time debugging experience.

[richlander]

You can do one of two things with non-root:

• Write to any directory under /home/app
• Create an other directory at the root that is writeable by app.

This makes the point to show the space that app owns.

$ docker run --rm -u app --entrypoint bash mcr.microsoft.com/dotnet/aspnet:8.0 -c "cd && pwd"
/home/app

[richlander]

Here's another "demo".

$ docker run --rm -u app -it  mcr.microsoft.com/dotnet/aspnet:8.0          
app@3ea21078f7fb:~$ whoami
app
app@3ea21078f7fb:/$ cd
app@3ea21078f7fb:~$ pwd
/home/app
app@3ea21078f7fb:~$ echo "hello world" > hello.txt
app@3ea21078f7fb:~$ cat hello.txt 
hello world

I am seeing an /app directory in your output. It is by design that you cannot write there. That's an important security feature characteristic and discussed in detail at: https://devblogs.microsoft.com/dotnet/securing-containers-with-rootless/#non-root-in-action. This is how non-root works with Docker, by default.

As suggested, the workaround is to write to the user directory. It's confusing because the "app" directory is called app and we named the user app. We maybe should have named the user dotnet, but that is also overloaded.

[LanceMcCarthy]

Ha! you beat me to it... I was waiting for the build & push to complete, but I've confirmed it works like a charm:

Part of my problem was indeed the mistake in assuming that $/app was an alias for /$home/app. Once I went straight to $HOME, everything I was trying earlier is working. this make complete sense now that I know that /app isn't the same thing. I guess I'm used to apps deploying to content under /home and still being writable.

For future consideration, you don't have to go so far as name the user dotnet, but maybe appuser would be enough to avoid this? I guess wait and see how much more trouble it causes.

I was already aware of these security considerations, and I agree an important part of cloud-native, no need to capitulate to root-like privileges, but just remember that .NET apps frequently need to write files. Maybe a variable for the writable folder would be useful, even something like %temp% that maps to /home/app/temp