Default diagnostic port regression in version 8.X

[Bluezen]

Description

Hello,
Since upgrading to version 8 of dotnet-monitor, we’ve noticed that no processes are being detected when using Connect mode and the default diagnostic port.

To reproduce this issue, start an application that exposes the /tmp folder in a volume (here named diag):

docker run -it -v diag:/tmp -p 8080:8080 mcr.microsoft.com/dotnet/samples:aspnetapp

then start dotnet-monitor with the same (diag) volume mounted:

docker run -it -v diag:/tmp -p 52323:52323 mcr.microsoft.com/dotnet/monitor:8 collect --urls "http://*:52323" --no-auth

When you access http://localhost:52323/processes, it returns an empty list []. We would expect to see some processes listed instead, like for example:

[{"pid":1,"uid":"79c27c06-eb74-4c49-bd41-93d6f4c4c93c","name":"aspnetapp","isDefault":true}]

as a dotnet-monitor in versions 6 or 7 behaved.

Regression?

To observe the change in behavior, simply update the version number to 7:

docker run -it -v diag:/tmp -p 52323:52323 mcr.microsoft.com/dotnet/monitor:7 collect --urls "http://*:52323" --no-auth

or version 6:

docker run -it -v diag:/tmp -p 52323:52323 mcr.microsoft.com/dotnet/monitor:6 --urls "http://*:52323" --no-auth

then access http://localhost:52323/processes, you should see some processes listed.

I’ve reviewed the documentation and couldn’t find any information about changes to configuration or behavior since version 8.
Am I overlooking something?

[github-actions]

Welcome to dotnet-monitor!

Thanks for creating your first issue; let us know what you think of dotnet-monitor by filling out our survey.

[schmittjoseph]

With .NET 8+ dotnet-monitor now runs as non-root in our images. This isn't an issue if both the application being monitored and dotnet-monitor run as the same user but if the users of the two applications mismatches, then we likely won't be able to connect. You can read more about this in our docs here.

When we originally released dotnet-monitor 8 the default ASP.NET sample application also ran as non-root so this wasn't an issue. It appears that this has since changed and the sample application run as root which means our image won't be able to monitor it.

Solutions (either will work):

1. Switch to using the mcr.microsoft.com/dotnet/samples:aspnetapp-chiseled image instead. This runs as the same user as our dotnet-monitor image and should just work.
2. Set the user of the mcr.microsoft.com/dotnet/samples:aspnetapp image to 1654:1654 (e.g. docker run -it --user 1654:1654 -v diag:/tmp -p 8080:8080 mcr.microsoft.com/dotnet/samples:aspnetapp)

We'll also look at updating our documentation around this.