Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Too many files are marked executable #9272

Open
sdmaclea opened this issue Dec 26, 2020 · 9 comments
Open

Too many files are marked executable #9272

sdmaclea opened this issue Dec 26, 2020 · 9 comments

Comments

@sdmaclea
Copy link

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

@sdmaclea sdmaclea added this to the 6.0.1xx milestone Dec 26, 2020
@marcpopMSFT
Copy link
Member

@dagood to take a look.

@dagood
Copy link
Member

dagood commented Jan 6, 2021

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:

<Target Name="ChmodLayout"
AfterTargets="CrossgenLayout"
Condition=" '$(OSName)' != 'win' ">
<Exec Command="find $(SdkOutputDirectory) -type d -exec chmod 755 {} \;" />
<Exec Command="find $(SdkOutputDirectory) -type f -exec chmod 644 {} \;" />
</Target>

/cc @NikolaMilosavljevic FYI


(apphost and singlefilehost templates are debatable).

For anyone curious what this means, there's a thread about it at dotnet/runtime#3843.

@sdmaclea
Copy link
Author

sdmaclea commented Jan 6, 2021

  • I don't think most/any of the SDK files should be writable either.
  • Execute permissions should be for all users too.

@sdmaclea
Copy link
Author

sdmaclea commented Jan 6, 2021

@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
Copy link
Member

dagood commented Jan 7, 2021

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
Copy link
Author

sdmaclea commented Feb 8, 2021

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
Copy link
Member

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

@dagood
Copy link
Member

dagood commented Oct 27, 2021

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

@dagood dagood reopened this Oct 27, 2021
@baronfel
Copy link
Member

@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.

@marcpopMSFT marcpopMSFT removed this from the 6.0.1xx milestone Jul 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants