Add a way to preserve or set file permissions on generated content

Currently, all content is created with the system default permissions since the original permissions aren’t inspected when being read from the template source.

We could either:

• Find a way to inspect the source permissions & expose that through the IFile abstraction & apply them (P/Invoke or a managed wrapper from somewhere) - this would be a breaking change

• Add a post-action to set permissions on generated files in the case that the system being run on supports chmod

Thoughts? @prafullbhosale @seancpeters @mhutch @sayedihashimi

[rmunn]

Long-term solution (the right way to go)

NuGet packages are .zip files, and the .zip file format includes 4 bytes (32 bits) for “external file attributes”. In theory, if the .zip file was created from a Unix-based system with the standard Unix zip tools (from the Info-Zip project), it will include the file’s original Unix permissions in the upper 16 bits of that 32-bit field. This is not well-documented anywhere, but the code for the standard Unix zip utilities is freely available, and the way Unix attributes are stored in the .zip file is visible in that code. Links to info sources:

• Documentation of the “external file attributes” field in the ZIP file format
• Git clone of the Info-Zip source
• Source code documenting how the external file attributes field is used
• Where those attributes are actually written to the zip file

See also https://stackoverflow.com/a/6297838/2314532 for more discussion of the zip file format’s “external file attribute” field, including its use in the standard Python library’s zipfile module.

Now, in practice, since NuGet was originally developed on (and for) Windows AFAICT, I rather doubt that .zip files created by NuGet are going to preserve the Unix file attributes in the same way that the Info-Zip tools do. But the best solution, ultimately, would be to make sure that that happens. This would probably also involve including an ExternalFileAttributes field (an int) in https://msdn.microsoft.com/en-us/library/system.io.compression.ziparchiveentry(v=vs.110).aspx, and ensuring that other Zip-handling tools in the .Net ecosystem learn about this field, and use it when they’re running on a Unix-like system.

Short-term solution (the right-now fix)

All of the above doesn’t do a thing to solve the immediate problem, because it will take years for the right fix (make .Net aware of this field in Zip files, and use it properly) to make its way through all the bits of code that need it. So the right now fix, I think, is something like the post-action suggestion made by @mlorbetske. HOWEVER, in the interest of keeping things as declarative as possible*, I suggest a specific post-action that goes along the lines of: “This is the list of filenames that should have their execute bit set if deploying on Unix.” Then the template author doesn’t have to write the chmod calls himself, he just has to make sure that any files that are supposed to be executable (e.g., build.sh scripts) are included in the list (wherever it may end up being) that controls that specific post-unpacking step.

* Declarative style always gives you more flexibility than imperative style, because with a declarative style, external tools can inspect the package and know what it will produce. Whereas if you have imperative steps in your packaging system, external tools cannot know what those imperative steps are going to do and whether that’s a security hole.

[rmunn]

Can confirm that this change did NOT make it into the 2.1.401 preview:

$ dotnet --version
2.1.401-preview-009202
$ dotnet new -i MiniScaffold
  Restoring packages for /home/rmunn/.templateengine/dotnetcli/v2.1.401-preview-009202/scratch/restore.csproj...
  Installing MiniScaffold 0.9.5.
  Generating MSBuild file /home/rmunn/.templateengine/dotnetcli/v2.1.401-preview-009202/scratch/obj/restore.csproj.nuget.g.props.
  Generating MSBuild file /home/rmunn/.templateengine/dotnetcli/v2.1.401-preview-009202/scratch/obj/restore.csproj.nuget.g.targets.
  Restore completed in 253.46 ms for /home/rmunn/.templateengine/dotnetcli/v2.1.401-preview-009202/scratch/restore.csproj.
$ dotnet new mini-scaffold -lang F#
The template "MiniScaffold" was created successfully.

Processing post-creation actions...
xdg-open: unexpected argument '+x'
Try 'xdg-open --help' for more information.
Unable to apply permissions +x to "*.sh".
Post action failed.
Description: Make scripts executable
Manual instructions: Run 'chmod +x *.sh'
$

😞

EDIT: I’m currently unable to find all the necessary packages to test the SDK 2.2 preview: https://github.com/dotnet/core-sdk/blob/master/README.md#installers-and-binaries has 2.2.100-preview1-009298-1, but https://github.com/dotnet/core-setup#daily-builds doesn’t yet have any 2.2 builds listed. My attempts to guess the URL for those builds let me to find https://dotnetcli.blob.core.windows.net/dotnet/Runtime/release/2.2/dotnet-runtime-deps-latest-x64.deb, but that’s 2.2.0~preview-26725-02. And trying https://dotnetcli.blob.core.windows.net/dotnet/Runtime/release/2.2.100/dotnet-runtime-deps-latest-x64.deb and https://dotnetcli.blob.core.windows.net/dotnet/Runtime/release/2.2.1xx/dotnet-runtime-deps-latest-x64.deb failed. I’ll update this issue with the results of testing against the .NET Core 2.2 SDK as soon as I can find the right packages to install, but I can’t do so yet.