dotnet-dump not working when process run as user

[valeriob]

Hi,
i think that collecting dumps in linux is still not really polished, i'm on Ubuntu 20.04 and dotnet 7, this is the process :

Run a dotnet7 application as user, in another console try to run
dotnet-dump collect -p
it fails with :

Writing full to /home/user/core_20231031_102955
[createdump] The process or container does not have permissions or access: open(/proc/7873/mem) FAILED Permission denied (13)
[createdump] Failure took 1ms

After 2h of reading and trying different things, the only way to collect a dump was to run the process as root, and run the dotnet-dump as root as well.

I did not find anything usefull in the docs, everybody talks about containers, and it was not usefull.
Thanks

[tommcdon]

@valeriob To help us understand the scenario where createdump failed, were you running the application on a system with a Linux Security Module enabled? For example, App Armor may block createdump from reading the target process's memory. We have marked this item as needing documentation to provide better guidance to customers where LSM's might interfere with diagnostics.

[valeriob]

Hi @tommcdon can you tell me how to check it, we are running on standard nvidia jetson platform, it's an ubuntu 18.04.

[vborioni-onit]

hi @tommcdon any update on this ? i checked we do not have Linux Security Module enabled.

[tommcdon]

Hi @vborioni-onit! I apologize for the delayed response!

The dotnet-dump collect command sends a Diagnostics IPC command to the target process requesting that it collect a dump. The target process listens on the IPC channel and then launches createdump. Createdump reads the parent process's memory and then writes the dump file out. It sounds like the IPC command succeeds, and then the target process successfully launches createdump, but createdump fails when attempting to read the parent process's memory via /proc/<pid>/mem.

Given that the OS is blocking reads from /proc/<pid>/mem, this issue is environmental and not product related. Based off of the description it sounds like containers are not in use, which rules out some of the default security related restrictions that can be enabled. With that said, this issue looks very similar to containerd/containerd#7695. Adding @hoyosjs for thoughts. I suggest reviewing any security related configuration on the host that might be blocking /proc/<pid>/mem access to child processes.

Out of curiosity, do you repro the issue following this tutorial? -- https://learn.microsoft.com/en-us/troubleshoot/developer/webapps/aspnetcore/practice-troubleshoot-linux/lab-3-troubleshoot-crash-gc-issues-dotnet-dump#collect-core-dump-files-by-using-dotnet-dump

[hoyosjs]

@valeriob do you happen to be using app armor or dropping/adding capabilities explicitly using setcap? Or anything interesting on how you're hosting the process.

[valeriob]

@valeriob do you happen to be using app armor or dropping/adding capabilities explicitly using setcap? Or anything interesting on how you're hosting the process.

Hi, we are using nVidia Jetson distribution, so it should be quite popular, it's based on ubuntu 18 or 20,
Those are the capabilities we added :

App armor does not seem to be present .

This is the output of the dotnet-dump collect command

Thank you