-
Notifications
You must be signed in to change notification settings - Fork 4.9k
Add file creation method that takes an ACL #42099
Conversation
src/System.IO.FileSystem.AccessControl/ref/System.IO.FileSystem.AccessControl.cs
Show resolved
Hide resolved
src/System.IO.FileSystem.AccessControl/src/System/IO/FileSystemAclExtensions.netcoreapp.cs
Show resolved
Hide resolved
src/System.IO.FileSystem.AccessControl/src/System/IO/FileSystemAclExtensions.netcoreapp.cs
Outdated
Show resolved
Hide resolved
src/System.IO.FileSystem.AccessControl/src/System/IO/FileSystemAclExtensions.netcoreapp.cs
Outdated
Show resolved
Hide resolved
src/System.IO.FileSystem.AccessControl/tests/FileSystemAclExtensionsTests.cs
Outdated
Show resolved
Hide resolved
src/System.IO.FileSystem.AccessControl/src/System/IO/FileSystemAclExtensions.netcoreapp.cs
Outdated
Show resolved
Hide resolved
src/System.IO.FileSystem.AccessControl/src/System/IO/FileSystemAclExtensions.netcoreapp.cs
Show resolved
Hide resolved
src/System.IO.FileSystem.AccessControl/src/System/IO/FileSystemAclExtensions.netcoreapp.cs
Show resolved
Hide resolved
src/System.IO.FileSystem.AccessControl/src/System/IO/FileSystemAclExtensions.netcoreapp.cs
Outdated
Show resolved
Hide resolved
src/System.IO.FileSystem.AccessControl/src/System/IO/FileSystemAclExtensions.netcoreapp.cs
Outdated
Show resolved
Hide resolved
|
The unit tests will fail with my latest commit. Some expected exceptions were different than expected, so I'm investigating. |
src/System.IO.FileSystem.AccessControl/src/System/IO/FileSystemAclExtensions.netcoreapp.cs
Show resolved
Hide resolved
src/System.IO.FileSystem.AccessControl/src/System/IO/FileSystemAclExtensions.netcoreapp.cs
Outdated
Show resolved
Hide resolved
src/System.IO.FileSystem.AccessControl/src/System/IO/FileSystemAclExtensions.netcoreapp.cs
Outdated
Show resolved
Hide resolved
src/System.IO.FileSystem.AccessControl/src/Resources/Strings.resx
Outdated
Show resolved
Hide resolved
src/System.IO.FileSystem.AccessControl/src/Resources/Strings.resx
Outdated
Show resolved
Hide resolved
src/System.IO.FileSystem.AccessControl/src/System/IO/FileSystemAclExtensions.netcoreapp.cs
Outdated
Show resolved
Hide resolved
src/System.IO.FileSystem.AccessControl/src/System/IO/FileSystemAclExtensions.netcoreapp.cs
Show resolved
Hide resolved
src/System.IO.FileSystem.AccessControl/src/System/IO/FileSystemAclExtensions.netcoreapp.cs
Outdated
Show resolved
Hide resolved
src/System.IO.FileSystem.AccessControl/src/System/IO/FileSystemAclExtensions.netcoreapp.cs
Outdated
Show resolved
Hide resolved
src/System.IO.FileSystem.AccessControl/src/System/IO/FileSystemAclExtensions.netcoreapp.cs
Outdated
Show resolved
Hide resolved
src/System.IO.FileSystem.AccessControl/tests/FileSystemAclExtensionsTests.cs
Outdated
Show resolved
Hide resolved
src/System.IO.FileSystem.AccessControl/tests/FileSystemAclExtensionsTests.cs
Outdated
Show resolved
Hide resolved
src/System.IO.FileSystem.AccessControl/src/Resources/Strings.resx
Outdated
Show resolved
Hide resolved
src/System.IO.FileSystem.AccessControl/src/Resources/Strings.resx
Outdated
Show resolved
Hide resolved
src/System.IO.FileSystem.AccessControl/src/System/IO/FileSystemAclExtensions.netcoreapp.cs
Outdated
Show resolved
Hide resolved
src/System.IO.FileSystem.AccessControl/tests/FileSystemAclExtensionsTests.cs
Show resolved
Hide resolved
|
@JeremyKuhne @danmosemsft @stephentoub @jkotas I have addressed the latest comments/suggestions and the build passed. Would you mind taking another look? |
src/System.IO.FileSystem.AccessControl/src/System/IO/FileSystemAclExtensions.netcoreapp.cs
Show resolved
Hide resolved
src/System.IO.FileSystem.AccessControl/src/System/IO/FileSystemAclExtensions.netcoreapp.cs
Show resolved
Hide resolved
src/System.IO.FileSystem.AccessControl/src/System/IO/FileSystemAclExtensions.netcoreapp.cs
Show resolved
Hide resolved
| } | ||
| if ((rights & FileSystemRights.WriteData) != 0 || ((int)rights & Interop.Kernel32.GenericOperations.GENERIC_WRITE) != 0) | ||
| { | ||
| access = access == FileAccess.Read ? FileAccess.ReadWrite : FileAccess.Write; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: our style would be to parenthesize
access = (access == FileAccess.Read) ? FileAccess.ReadWrite : FileAccess.Write;
|
|
||
| Assert.Throws<ArgumentNullException>("fileInfo", () => | ||
| { | ||
| if (PlatformDetection.IsFullFramework) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit, there's a bunch of repetition among these tests, you could do
private void FileInfoCreate(info, mode, rights, share, buffer, options, security)
{
if (PlatformDetection.IsFullFramework)
{
FileSystemAclExtensions.Create(....);
}
else
{
info.Create(...);
}
}Then your test would be just eg
[Fact]
public void FileInfo_Create_NullFileSecurity()
{
FileInfo info = new FileInfo("path");
Assert.Throws<ArgumentNullException>("fileSecurity", () => FileInfoCreate(info, FileMode.Create, FileSystemRights.WriteData, FileShare.Read, DefaultBufferSize, FileOptions.None, null);
}There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or - another idea. You could have a separate source file that's only included when building tests for .NET Framework which defines your new extension method and just passes it through to the .NET Framework method. That might be nice because the tests themselves don't need to know it exists. They just call the .NET Core method.
If it's worth doing, you coudl do it later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally you want tests to be short and sweet, because that makes it easier to see what changes between them (what the test cases are)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Totally understood, @danmosemsft . Would it be ok if I address this in a separate PR so I get this merged today?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good call
danmoseley
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Feel free to defer any minor things until after the port.
Approved API Proposal: #41614 Related change for directory creation method that takes an ACL: #41834 -merged and ported to 3.1 Prev2 Description We have extension methods in System.IO.FileSystem.AclExtensions that let the user get and set ACLs for existing files, but we do not have methods that create files with predefined ACLs. .NET ACL (Access Control List) support is Windows specific. This change will reside inside the System.IO.FileSystem.AccessControl assembly. Customer impact Before this change, customers had to create a file or filestream, then set its ACLs. This presents a few problems: Potential security hole as files can be accessed between creation and modification. Porting difficulties as there isn't a 1-1 API replacement Stability issues with background processes (file filters) can prevent modifying ACLs right after creation (typically surfaces as a security exception). This change addresses those problems by adding a new extension method that allows creating a file and ensuring the provided ACLs are set during creation. This change is expected to be backported to 3.1. Signed-off-by: dotnet-bot <dotnet-bot@microsoft.com>
Approved API Proposal: #41614 Related change for directory creation method that takes an ACL: #41834 -merged and ported to 3.1 Prev2 Description We have extension methods in System.IO.FileSystem.AclExtensions that let the user get and set ACLs for existing files, but we do not have methods that create files with predefined ACLs. .NET ACL (Access Control List) support is Windows specific. This change will reside inside the System.IO.FileSystem.AccessControl assembly. Customer impact Before this change, customers had to create a file or filestream, then set its ACLs. This presents a few problems: Potential security hole as files can be accessed between creation and modification. Porting difficulties as there isn't a 1-1 API replacement Stability issues with background processes (file filters) can prevent modifying ACLs right after creation (typically surfaces as a security exception). This change addresses those problems by adding a new extension method that allows creating a file and ensuring the provided ACLs are set during creation. This change is expected to be backported to 3.1. Signed-off-by: dotnet-bot <dotnet-bot@microsoft.com>
Approved API Proposal: #41614 Related change for directory creation method that takes an ACL: #41834 -merged and ported to 3.1 Prev2 Description We have extension methods in System.IO.FileSystem.AclExtensions that let the user get and set ACLs for existing files, but we do not have methods that create files with predefined ACLs. .NET ACL (Access Control List) support is Windows specific. This change will reside inside the System.IO.FileSystem.AccessControl assembly. Customer impact Before this change, customers had to create a file or filestream, then set its ACLs. This presents a few problems: Potential security hole as files can be accessed between creation and modification. Porting difficulties as there isn't a 1-1 API replacement Stability issues with background processes (file filters) can prevent modifying ACLs right after creation (typically surfaces as a security exception). This change addresses those problems by adding a new extension method that allows creating a file and ensuring the provided ACLs are set during creation. This change is expected to be backported to 3.1. Signed-off-by: dotnet-bot <dotnet-bot@microsoft.com>
Approved API Proposal: #41614 Related change for directory creation method that takes an ACL: #41834 -merged and ported to 3.1 Prev2 Description We have extension methods in System.IO.FileSystem.AclExtensions that let the user get and set ACLs for existing files, but we do not have methods that create files with predefined ACLs. .NET ACL (Access Control List) support is Windows specific. This change will reside inside the System.IO.FileSystem.AccessControl assembly. Customer impact Before this change, customers had to create a file or filestream, then set its ACLs. This presents a few problems: Potential security hole as files can be accessed between creation and modification. Porting difficulties as there isn't a 1-1 API replacement Stability issues with background processes (file filters) can prevent modifying ACLs right after creation (typically surfaces as a security exception). This change addresses those problems by adding a new extension method that allows creating a file and ensuring the provided ACLs are set during creation. This change is expected to be backported to 3.1. Signed-off-by: dotnet-bot <dotnet-bot@microsoft.com>
* Revert removal of SuppressGCTransition from SystemNative_GetTimestamp() (#27473) * Revert removal of SuppressGCTransition from SystemNative_GetTimestamp() * Insert GC_POLL before statement with unmanaged call. * JIT test for insertion of GCPoll Signed-off-by: dotnet-bot <dotnet-bot@microsoft.com> * Add file creation method that takes an ACL (dotnet/corefx#42099) Approved API Proposal: #41614 Related change for directory creation method that takes an ACL: #41834 -merged and ported to 3.1 Prev2 Description We have extension methods in System.IO.FileSystem.AclExtensions that let the user get and set ACLs for existing files, but we do not have methods that create files with predefined ACLs. .NET ACL (Access Control List) support is Windows specific. This change will reside inside the System.IO.FileSystem.AccessControl assembly. Customer impact Before this change, customers had to create a file or filestream, then set its ACLs. This presents a few problems: Potential security hole as files can be accessed between creation and modification. Porting difficulties as there isn't a 1-1 API replacement Stability issues with background processes (file filters) can prevent modifying ACLs right after creation (typically surfaces as a security exception). This change addresses those problems by adding a new extension method that allows creating a file and ensuring the provided ACLs are set during creation. This change is expected to be backported to 3.1. Signed-off-by: dotnet-bot <dotnet-bot@microsoft.com>
Approved API Proposal: #41614 Related change for directory creation method that takes an ACL: #41834 -merged and ported to 3.1 Prev2 Description We have extension methods in System.IO.FileSystem.AclExtensions that let the user get and set ACLs for existing files, but we do not have methods that create files with predefined ACLs. .NET ACL (Access Control List) support is Windows specific. This change will reside inside the System.IO.FileSystem.AccessControl assembly. Customer impact Before this change, customers had to create a file or filestream, then set its ACLs. This presents a few problems: Potential security hole as files can be accessed between creation and modification. Porting difficulties as there isn't a 1-1 API replacement Stability issues with background processes (file filters) can prevent modifying ACLs right after creation (typically surfaces as a security exception). This change addresses those problems by adding a new extension method that allows creating a file and ensuring the provided ACLs are set during creation. This change is expected to be backported to 3.1. Signed-off-by: dotnet-bot <dotnet-bot@microsoft.com>
Approved API Proposal: dotnet/corefx#41614 Related change for directory creation method that takes an ACL: dotnet/corefx#41834 -merged and ported to 3.1 Prev2 Description We have extension methods in System.IO.FileSystem.AclExtensions that let the user get and set ACLs for existing files, but we do not have methods that create files with predefined ACLs. .NET ACL (Access Control List) support is Windows specific. This change will reside inside the System.IO.FileSystem.AccessControl assembly. Customer impact Before this change, customers had to create a file or filestream, then set its ACLs. This presents a few problems: Potential security hole as files can be accessed between creation and modification. Porting difficulties as there isn't a 1-1 API replacement Stability issues with background processes (file filters) can prevent modifying ACLs right after creation (typically surfaces as a security exception). This change addresses those problems by adding a new extension method that allows creating a file and ensuring the provided ACLs are set during creation. This change is expected to be backported to 3.1. Commit migrated from dotnet/corefx@508cbc4
Approved API Proposal: #41614
Related change for directory creation method that takes an ACL: #41834 [merged and ported to 3.1 Prev2]
Description
We have extension methods in System.IO.FileSystem.AclExtensions that let the user get and set ACLs for existing files, but we do not have methods that create files with predefined ACLs.
.NET ACL (Access Control List) support is Windows specific. This change will reside inside the System.IO.FileSystem.AccessControl assembly.
Customer impact
Before this change, customers had to create a file or filestream, then set its ACLs. This presents a few problems:
This change is expected to be backported to 3.1.