dotnet / installer

.NET SDK Installer
https://github.com/dotnet/sdk
1.27k stars 446 forks source link

Too many files are marked executable #9272

Open sdmaclea opened 3 years ago

sdmaclea commented 3 years ago

Too many files are marked executable. (while I've only looked at the osx-arm64 build, I would guess this is a general problem.

% find ../dotnet-sdk-6.0.100-alpha.1.20625.2-osx-arm64 -perm +111 -type f | wc -l   
     498

The reasonable set of executable binaries would be these. (apphost and singlefilehost templates are debatable).

steve@Toms-Mac-2 helloWorld % find ../dotnet-sdk-6.0.100-alpha.1.20625.2-osx-arm64 -perm +111 -type f -not '(' -name \*.dll -o -name \*.dylib -o -name \*.xml -o -name \*.txt -o -name \*.a -o -name \*.h ')'
../dotnet-sdk-6.0.100-alpha.1.20625.2-osx-arm64/shared/Microsoft.NETCore.App/6.0.0-alpha.1.20624.8/createdump
../dotnet-sdk-6.0.100-alpha.1.20625.2-osx-arm64/dotnet
../dotnet-sdk-6.0.100-alpha.1.20625.2-osx-arm64/packs/Microsoft.NETCore.App.Host.osx-arm64/6.0.0-alpha.1.20624.8/runtimes/osx-arm64/native/apphost
../dotnet-sdk-6.0.100-alpha.1.20625.2-osx-arm64/packs/Microsoft.NETCore.App.Host.osx-arm64/6.0.0-alpha.1.20624.8/runtimes/osx-arm64/native/singlefilehost
../dotnet-sdk-6.0.100-alpha.1.20625.2-osx-arm64/sdk/6.0.100-alpha.1.20625.2/AppHostTemplate/apphost

We are marking dll, xml, dylib, txt, h and a extensions executable. None of these represent executable programs.

% find ../dotnet-sdk-6.0.100-alpha.1.20625.2-osx-arm64 -perm +111 -type f -name \*.dll | wc -l   
     318
% find ../dotnet-sdk-6.0.100-alpha.1.20625.2-osx-arm64 -perm +111 -type f -name \*.xml | wc -l 
     153
% find ../dotnet-sdk-6.0.100-alpha.1.20625.2-osx-arm64 -perm +111 -type f -name \*.dylib | wc -l 
      14
% find ../dotnet-sdk-6.0.100-alpha.1.20625.2-osx-arm64 -perm +111 -type f -name \*.txt | wc -l 
       4
% find ../dotnet-sdk-6.0.100-alpha.1.20625.2-osx-arm64 -perm +111 -type f -name \*.h | wc -l 
       3
% find ../dotnet-sdk-6.0.100-alpha.1.20625.2-osx-arm64 -perm +111 -type f -name \*.a | wc -l 
       1

This issue probably belongs in another repo (arcade?), but symptoms cross dependent repos

 % for i in $(find ../dotnet-sdk-6.0.100-alpha.1.20625.2-osx-arm64 -perm +111 -type f '(' -name \*.dll -o -name \*.dylib -o -name \*.xml -o -name \*.txt -o -name \*.a -o -name \*.h ')' | sort -f ); do dirname $i; done | sort -f | uniq
../dotnet-sdk-6.0.100-alpha.1.20625.2-osx-arm64/host/fxr/6.0.0-alpha.1.20624.8
../dotnet-sdk-6.0.100-alpha.1.20625.2-osx-arm64/packs/Microsoft.AspNetCore.App.Ref/6.0.0-alpha.1.20624.2/data
../dotnet-sdk-6.0.100-alpha.1.20625.2-osx-arm64/packs/Microsoft.AspNetCore.App.Ref/6.0.0-alpha.1.20624.2/ref/net6.0
../dotnet-sdk-6.0.100-alpha.1.20625.2-osx-arm64/packs/Microsoft.NETCore.App.Host.osx-arm64/6.0.0-alpha.1.20624.8/runtimes/osx-arm64/native
../dotnet-sdk-6.0.100-alpha.1.20625.2-osx-arm64/packs/Microsoft.NETCore.App.Ref/6.0.0-alpha.1.20624.8/data
../dotnet-sdk-6.0.100-alpha.1.20625.2-osx-arm64/packs/Microsoft.NETCore.App.Ref/6.0.0-alpha.1.20624.8/ref/net6.0
../dotnet-sdk-6.0.100-alpha.1.20625.2-osx-arm64/packs/NETStandard.Library.Ref/2.1.0/data
../dotnet-sdk-6.0.100-alpha.1.20625.2-osx-arm64/packs/NETStandard.Library.Ref/2.1.0/ref/netstandard2.1
../dotnet-sdk-6.0.100-alpha.1.20625.2-osx-arm64/shared/Microsoft.NETCore.App/6.0.0-alpha.1.20624.8

/cc @jkoritzinsky @ViktorHofer @mmitche

marcpopMSFT commented 3 years ago

@dagood to take a look.

dagood commented 3 years ago

I checked an apphost tar.gz output from a dotnet/runtime daily build and the problem isn't there in the original artifact. (Except for libnethost.dylib.) dotnet-apphost-pack-6.0.0-alpha.1.21056.6-osx-arm64.tar.gz:

image

vs. dotnet-sdk-6.0.100-alpha.1.21056.8-osx-arm64.tar.gz from dotnet/installer readme:

image

This target looks like it's doing this intentionally:

https://github.com/dotnet/installer/blob/01930deb2a897ba302d89dacbe15a0622f2ecf0c/src/redist/targets/Crossgen.targets#L158-L164

/cc @NikolaMilosavljevic FYI


(apphost and singlefilehost templates are debatable).

For anyone curious what this means, there's a thread about it at https://github.com/dotnet/runtime/issues/3843.

sdmaclea commented 3 years ago
sdmaclea commented 3 years ago

@dagood Hmmm

<Exec Command="find $(SdkOutputDirectory) -type f -exec chmod 644 {} \;" /> 

On second thought 644 is rw-r--r-- so that is not the correct root cause.

dagood commented 3 years ago

Oh... right. 😄 Well, the nupkgs (Microsoft.NETCore.App.Host.osx-arm64) don't persist permission bits and NuGet restore extracts them as 744, which matches. I guess the SDK layout uses the nupkgs, not the tar.gzs.

sdmaclea commented 3 years ago

I did look at the preview1 installer. The dlls are not marked executable. The dylibs are though. Per @janvorli, XCode marks dylibs as executable by default and we have just left them as executable.

I di see that when we published --self-contained the sdk installed the dlls as executable though.

marcpopMSFT commented 3 years ago

Did this end up getting fixed in 6.0.100 and can be closed? Reactivate if not.

dagood commented 3 years ago

This hasn't changed. Here's a fresh screenshot of dotnet-sdk-6.0.100-osx-arm64.tar.gz packs\Microsoft.NETCore.App.Host.osx-arm64\6.0.0\runtimes\osx-arm64\native\:

image

baronfel commented 5 months ago

@marcpopMSFT this is still a thing - the latest Linux binaries (8.0.300) have the executable bit marked on so many unnecessary files. When I extracted the tarball every file and directory in it had rwx permissions for user, group, and other.