Runtime: Need one step API for creating files on Windows with security

[JeremyKuhne]

The Framework (NetFX) APIs for applying security to created files are as follows:

``` C#
namespace System.IO
{
public static class File
{
public static FileStream Create(string path, int bufferSize, FileOptions options, FileSecurity fileSecurity);
}

public static class Directory
{
    public static DirectoryInfo CreateDirectory(string path, DirectorySecurity directorySecurity);
}

public class FileStream : Stream
{
    public FileStream(string path, FileMode mode, FileSystemRights rights, FileShare share, int bufferSize, FileOptions options, FileSecurity fileSecurity);
}

}

The Windows specific security in .NET Core is in `System.IO.FileSystem.AccessControl`. We currently have no way to set security before creating an object. To facilitate porting from .NET Framework we should add some static helpers to `FileSecurity` and `DirectorySecurity` that allow doing this in one step. Not only is this easier, it is safer than trying to add to an existing object.

``` C#
namespace System.Security.AccessControl
{
    public sealed partial class FileSecurity : System.Security.AccessControl.FileSystemSecurity
    {
        public static FileStream CreateFileStream(string path, int bufferSize, FileOptions options, FileSecurity fileSecurity);
        public static FileStream CreateFileStream(string path, FileMode mode, FileSystemRights rights, FileShare share, int bufferSize, FileOptions options, FileSecurity fileSecurity);
    }

    public sealed partial class DirectorySecurity : System.Security.AccessControl.FileSystemSecurity
    {
        public static DirectoryInfo CreateDirectory(string path, DirectorySecurity directorySecurity);
    }
}

These APIs are showing up in customer projects that they're attempting to move to Core.

cc: @pjanotti, @danmosemsft

[JeremyKuhne]

While we could, in theory, add the .NET Framework APIs as-is, it would create a library dependency and complexity/confusion for both Windows and Unix. (We'd have to eventually add Unix specific ACL support here as well.)

[terrajobst]

Video

@JeremyKuhne

What would it look like if were to add them back where they were? How bad would the dependency be? These APIs show up a lot in porting.

[danmosemsft]

@JeremyKuhne when you have cycles could you look at how bad it would be to bring these back as was ? We continue to get feedback from porters.

[nguerrera]

Please add them back as they were so that existing binaries can work. I think we can have a capability API + PlatformNotSupportedException.

[JeremyKuhne]

It isn't super difficult, maybe a week? One proposal was to add these, but not to the ref so existing binaries will run. We can then include System.IO.FileSystem.AccessControl only for the Windows build. I'd be much happier to force new writers of code to the other assembly.

@terrajobst, @ericstj what do you think is the best course of action?

[jkotas]

Adding them as they were would mean folding all or large parts of System.IO.FIleSystem.AccessControl and Sysrtem.IO.FIleSystem into System.Private.CoreLib. Is it correct?

[JeremyKuhne]

Adding them as they were would mean folding all or large parts of System.IO.FIleSystem.AccessControl and Sysrtem.IO.FIleSystem into System.Private.CoreLib. Is it correct?

Thanks, if we do FileStream, yes. If we just do the others we can avoid that. I think we've been mostly hitting this on File.Create, but I could be wrong.

I _really_ don't want to add this back to FileStream in CoreLib.

[nguerrera]

Representing customer for dotnet/corefx#33719, I saw the issue with (File|Directory).(Create|SetAccessControl), not FileStream.

I imagine we can look at API port data for this?

[nguerrera]

Could it be avoided by doing the better factored statics as Jeremy proposed in the issue description with the legacy statics using reflection to use the newer statics? Or did you have some other way of avoiding this?

[danmosemsft]

@nguerrera the method signatures accept DirectorySecurity, eg., public static DirectoryInfo CreateDirectory(string path, DirectorySecurity directorySecurity);. Even if the implementation uses reflection, the DirectorySecurity type needs to be moved down, and there are a lot of public members on it (or its base class) each consuming other types like FileSystemAccessRule etc so those would have to come down and at that point reflection is probably just worse than moving everything.

[nguerrera]

Ah, right, nevermind

[JeremyKuhne]

Closing in favor of dotnet/corefx#41614.