createdump lacking exec bit on macOS PKG installers

[hoyosjs]

Description

Regressed in the installer:

-rw-r--r--  1 root  wheel   201K Oct  2 15:56 /usr/local/share/dotnet/shared/Microsoft.NETCore.App/10.0.0-rc.2.25502.107/createdump
-rwxr-xr-x  1 root  wheel   185K Sep 26 11:21 /usr/local/share/dotnet/shared/Microsoft.NETCore.App/9.0.10/createdump
-rwxr-xr-x  1 root  wheel   185K Sep 26 11:50 /usr/local/share/dotnet/shared/Microsoft.NETCore.App/8.0.21/createdump

That same bit is present in tar install of runtime or SDK.

Reproduction Steps

Install runtime from https://dot.net/downloads

Expected behavior

Crashes and dotnet-dump collect should work.

Actual behavior

createdump fails to execute.

Regression?

Yes, from 9.0

Known Workarounds

Add exec bit manually.

Configuration

Any macOS 10.0 PKG installed runtime

Other information

No response

[dotnet-policy-service]

Tagging subscribers to this area: @steveisok, @dotnet/dotnet-diag
See info in area-owners.md if you want to be subscribed.

[hoyosjs]

Looks like Target Name="PublishToDisk" isn't finding createdump as part of its find.

[hoyosjs]

In https://github.com/dotnet/arcade/blob/d8816877a6b0e6cb39cb57d92557ad4952715a2e/src/Microsoft.DotNet.SharedFramework.Sdk/targets/sharedfx.targets#L621-L624

The dylibs are also not getting exec perms. Oddly enough this goes as far back as 20250816.5 on VMR 10.0 - but VMR main is OK. I have a feeling this is related to the way signing is handling pkgs.

[am11]

The shared libs (dylib/so) don't need to be executable. When loading a dylib without the executable bit, the loader uses mmap and read permissions, not dependent on the filesystem exec bit.

[hoyosjs]

dotnet/dotnet#2491 this wasn't a fix for this case.

[hoyosjs]

@am11 - not saying it needs them. But rather that something stripped it. It seems like it was signing indeed.

[hoyosjs]

-rw-r--r--  1 root  wheel    158528 Sep  1 17:52 /usr/local/share/dotnet/packs/Microsoft.NETCore.App.Host.osx-arm64/10.0.0-rc.1.25451.107/runtimes/osx-arm64/native/apphost
-rw-r--r--  1 root  wheel  10715520 Sep  1 17:52 /usr/local/share/dotnet/packs/Microsoft.NETCore.App.Host.osx-arm64/10.0.0-rc.1.25451.107/runtimes/osx-arm64/native/singlefilehost
-rw-r--r--  1 root  wheel    158528 Oct  2 15:56 /usr/local/share/dotnet/packs/Microsoft.NETCore.App.Host.osx-arm64/10.0.0-rc.2.25502.107/runtimes/osx-arm64/native/apphost
-rw-r--r--  1 root  wheel  10733200 Oct  2 15:56 /usr/local/share/dotnet/packs/Microsoft.NETCore.App.Host.osx-arm64/10.0.0-rc.2.25502.107/runtimes/osx-arm64/native/singlefilehost
-rwxr-xr-x  1 root  wheel    140512 Sep 26 11:50 /usr/local/share/dotnet/packs/Microsoft.NETCore.App.Host.osx-arm64/8.0.21/runtimes/osx-arm64/native/apphost
-rwxr-xr-x  1 root  wheel  10383408 Sep 26 11:50 /usr/local/share/dotnet/packs/Microsoft.NETCore.App.Host.osx-arm64/8.0.21/runtimes/osx-arm64/native/singlefilehost
-rwxr-xr-x  1 root  wheel    139536 Oct 29  2024 /usr/local/share/dotnet/packs/Microsoft.NETCore.App.Host.osx-arm64/9.0.0/runtimes/osx-arm64/native/apphost
-rwxr-xr-x  1 root  wheel  10994336 Oct 29  2024 /usr/local/share/dotnet/packs/Microsoft.NETCore.App.Host.osx-arm64/9.0.0/runtimes/osx-arm64/native/singlefilehost
-rwxr-xr-x  1 root  wheel    141024 Sep 26 11:21 /usr/local/share/dotnet/packs/Microsoft.NETCore.App.Host.osx-arm64/9.0.10/runtimes/osx-arm64/native/apphost
-rwxr-xr-x  1 root  wheel  10807024 Sep 26 11:21 /usr/local/share/dotnet/packs/Microsoft.NETCore.App.Host.osx-arm64/9.0.10/runtimes/osx-arm64/native/singlefilehost
-rwxr-xr-x  1 root  wheel    140896 May 19 18:58 /usr/local/share/dotnet/packs/Microsoft.NETCore.App.Host.osx-arm64/9.0.6/runtimes/osx-arm64/native/apphost
-rwxr-xr-x  1 root  wheel  10806864 May 19 18:58 /usr/local/share/dotnet/packs/Microsoft.NETCore.App.Host.osx-arm64/9.0.6/runtimes/osx-arm64/native/singlefilehost

This regression also affects the in-box pkg apphost and SF host (cc: @agocke @mmitche )

[agocke]

Host should be OK, we chmod in the writer:

runtime/src/installer/managed/Microsoft.NET.HostModel/AppHost/HostWriter.cs

Line 182 in 9f1cab7

if (!RuntimeInformation.IsOSPlatform(OSPlatform.Windows))

[mmitche]

@am11 - not saying it needs them. But rather that something stripped it. It seems like it was signing indeed.

Did you eliminate signing as the culprit here?