diagnostics: C# service not able to produce runtime coredumps from unhandled exception, if the container runs as non-root

The C# service is not able to produce coredumps(generated by runtime) if the container is running with non-root user id.

Configuration

Os and version info - Linux prober-prober-784866ff9c-9nx4j 4.15.0-1091-azure #101~16.04.1-Ubuntu SMP Fri Jun 26 01:14:12 UTC 2020 x86_64 GNU/Linux

deployment.yaml file contains:

containers:
        securityContext:
          capabilities:
            add:
            - SYS_PTRACE
          runAsUser: 300
        env:
          - name: COMPlus_DbgEnableMiniDump
            value: "1"
          - name: COMPlus_DbgMiniDumpType
            value: "4"
          - name: COMPlus_DbgMiniDumpName
            value: "/cores/prober-core-%d"

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Reactions: 1
  • Comments: 29 (17 by maintainers)

Most upvoted comments

I think we got sidetracked here with the permissions of the directory the core dump is written too. The actual error (which isn’t in the issue) is:

open(/proc/1/mem) FAILED 13 (Permission denied)

This is in createdump itself when it opens the special Linux file for reading the target runtime process memory. When createdump is launched by the runtime it does a prctl(PR_SET_PTRACER, childpid, ... call that outside of a docker container and any container I’ve created allows that open to succeed without requiring the runtime be running as root.

I don’t have any answers yet.

using COPY in docker maintains the permissions on the files. So the files were owned by root:root, but the process was being started by a lower privileges user using runAsUser. So when the runtime forked to use createdump, the exec/execv failed due to ownership. This only happened since the customer in question used a self-contained deployment (as opposed to framework-dependent)

okay so I changed the permissions for /var/log/core-dump on the host itself and it reflected in /cores.

drwxrwxrwx 4 root root 4096 Oct 29 19:00 cores

but still the core-dumps are not getting generated.

@sdmaclea When I start the container as user 300, I see

drwxrwx— 2 root root 4096 Oct 29 16:58 cores