OEL
/
NTFSSecurity
mirror of https://github.com/raandree/NTFSSecurity
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
199 Commits
1 Branch
12 Tags
13 MiB
Tree: 0b92b69d53
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '0b92b69d53'
${ noResults }
NTFSSecurity/Security2/FileSystem/FileSystemAuditRule2 Class/FileSystemAuditRule2.Remove...

123 lines
5.1 KiB
Raw Normal View History

new upload
10 years ago
using Alphaleonis.Win32.Filesystem;
using System.Collections.Generic;
using System.Security.AccessControl;
namespace Security2
{
public partial class FileSystemAuditRule2
{
fix: restore -RemoveSpecific in Remove-NTFSAccess and Remove-NTFSAudit Defect 17. Both cmdlets carried a removeSpecific field that no parameter set, so they always took the rights away from matching entries; the version history documents a -RemoveSpecific switch since 4.1. Both cmdlets now have the switch, which removes only an entry that matches exactly. The Security2 list overloads didn't pass the flag on, and the audit item overload didn't support it; all overloads now do. The applies-to field of both cmdlets is initialized; -AppliesTo is mandatory in the Simple sets since defect 14, so it is always set when used. Tests: Access.Tests.ps1 3 tests, Audit.Tests.ps1 2 tests, on in-memory security descriptors. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: AI Assistant <ai@example.com>
4 weeks ago
public static void RemoveFileSystemAuditRule(FileSystemInfo item, IdentityReference2 account, FileSystemRights2 rights, AuditFlags type, InheritanceFlags inheritanceFlags, PropagationFlags propagationFlags, bool removeSpecific = false)
new upload
10 years ago
{
FileSystemAuditRule ace = null;
if (item is FileInfo)
{
var file = (FileInfo)item;
var sd = file.GetAccessControl(AccessControlSections.Audit);
ace = (FileSystemAuditRule)sd.AuditRuleFactory(account, (int)rights, false, inheritanceFlags, propagationFlags, type);
fix: restore -RemoveSpecific in Remove-NTFSAccess and Remove-NTFSAudit Defect 17. Both cmdlets carried a removeSpecific field that no parameter set, so they always took the rights away from matching entries; the version history documents a -RemoveSpecific switch since 4.1. Both cmdlets now have the switch, which removes only an entry that matches exactly. The Security2 list overloads didn't pass the flag on, and the audit item overload didn't support it; all overloads now do. The applies-to field of both cmdlets is initialized; -AppliesTo is mandatory in the Simple sets since defect 14, so it is always set when used. Tests: Access.Tests.ps1 3 tests, Audit.Tests.ps1 2 tests, on in-memory security descriptors. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: AI Assistant <ai@example.com>
4 weeks ago
if (removeSpecific)
sd.RemoveAuditRuleSpecific(ace);
else
sd.RemoveAuditRule(ace);
new upload
10 years ago
fix: write only the sections of the security descriptor that a cmdlet changes The access and audit cmdlets wrote the owner of an item back with the entries they changed. For a DACL without the auto-inherit flag, Windows returns the owner and the group even when only the DACL is read, and the cmdlets wrote every section that the descriptor held. Without the Restore privilege, or on a file server that refuses the owner, the write failed with error 1307 (#34). - Add-NTFSAccess, Clear-NTFSAccess, Add-NTFSAudit, and Clear-NTFSAudit read only the DACL or the SACL. FileSystemSecurity2.Write(), Remove-NTFSAccess, and Remove-NTFSAudit write only the sections they read, which also fixes the access inheritance cmdlets. - Read together with the SACL, the inherited entries of such a DACL lose their inherited flag when the parent folder has no SACL, and the cmdlets stored them as explicit copies. Get-NTFSSecurityDescriptor now reads the DACL in a separate call. - Set-NTFSSecurityDescriptor writes only the sections that changed since they were read; an unchanged descriptor writes nothing (maintainer decision of 2026-10-06). - Clear-NTFSAudit writes nothing for an item without a SACL, and reports an error without the Security privilege (maintainer decision). The regression tests failed before and pass after the fix in Windows PowerShell 5.1 and PowerShell 7, elevated and as a basic user. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: AI Assistant <ai@example.com>
4 weeks ago
// Only the SACL, so that no other section that Windows returns with it is written back (#34)
file.SetAccessControl(sd, AccessControlSections.Audit);
new upload
10 years ago
}
else
{
DirectoryInfo directory = (DirectoryInfo)item;
var sd = directory.GetAccessControl(AccessControlSections.Audit);
ace = (FileSystemAuditRule)sd.AuditRuleFactory(account, (int)rights, false, inheritanceFlags, propagationFlags, type);
fix: restore -RemoveSpecific in Remove-NTFSAccess and Remove-NTFSAudit Defect 17. Both cmdlets carried a removeSpecific field that no parameter set, so they always took the rights away from matching entries; the version history documents a -RemoveSpecific switch since 4.1. Both cmdlets now have the switch, which removes only an entry that matches exactly. The Security2 list overloads didn't pass the flag on, and the audit item overload didn't support it; all overloads now do. The applies-to field of both cmdlets is initialized; -AppliesTo is mandatory in the Simple sets since defect 14, so it is always set when used. Tests: Access.Tests.ps1 3 tests, Audit.Tests.ps1 2 tests, on in-memory security descriptors. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: AI Assistant <ai@example.com>
4 weeks ago
if (removeSpecific)
sd.RemoveAuditRuleSpecific(ace);
else
sd.RemoveAuditRule(ace);
new upload
10 years ago
fix: write only the sections of the security descriptor that a cmdlet changes The access and audit cmdlets wrote the owner of an item back with the entries they changed. For a DACL without the auto-inherit flag, Windows returns the owner and the group even when only the DACL is read, and the cmdlets wrote every section that the descriptor held. Without the Restore privilege, or on a file server that refuses the owner, the write failed with error 1307 (#34). - Add-NTFSAccess, Clear-NTFSAccess, Add-NTFSAudit, and Clear-NTFSAudit read only the DACL or the SACL. FileSystemSecurity2.Write(), Remove-NTFSAccess, and Remove-NTFSAudit write only the sections they read, which also fixes the access inheritance cmdlets. - Read together with the SACL, the inherited entries of such a DACL lose their inherited flag when the parent folder has no SACL, and the cmdlets stored them as explicit copies. Get-NTFSSecurityDescriptor now reads the DACL in a separate call. - Set-NTFSSecurityDescriptor writes only the sections that changed since they were read; an unchanged descriptor writes nothing (maintainer decision of 2026-10-06). - Clear-NTFSAudit writes nothing for an item without a SACL, and reports an error without the Security privilege (maintainer decision). The regression tests failed before and pass after the fix in Windows PowerShell 5.1 and PowerShell 7, elevated and as a basic user. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: AI Assistant <ai@example.com>
4 weeks ago
directory.SetAccessControl(sd, AccessControlSections.Audit);
new upload
10 years ago
}
}
public static void RemoveFileSystemAuditRule(FileSystemInfo item, List<IdentityReference2> accounts, FileSystemRights2 rights, AuditFlags type, InheritanceFlags inheritanceFlags, PropagationFlags propagationFlags, bool removeSpecific = false)
{
foreach (var account in accounts)
{
fix: restore -RemoveSpecific in Remove-NTFSAccess and Remove-NTFSAudit Defect 17. Both cmdlets carried a removeSpecific field that no parameter set, so they always took the rights away from matching entries; the version history documents a -RemoveSpecific switch since 4.1. Both cmdlets now have the switch, which removes only an entry that matches exactly. The Security2 list overloads didn&#39;t pass the flag on, and the audit item overload didn&#39;t support it; all overloads now do. The applies-to field of both cmdlets is initialized; -AppliesTo is mandatory in the Simple sets since defect 14, so it is always set when used. Tests: Access.Tests.ps1 3 tests, Audit.Tests.ps1 2 tests, on in-memory security descriptors. Co-authored-by: Copilot &lt;223556219+Copilot@users.noreply.github.com&gt; Co-authored-by: AI Assistant &lt;ai@example.com&gt;
4 weeks ago
RemoveFileSystemAuditRule(item, account, rights, type, inheritanceFlags, propagationFlags, removeSpecific);
new upload
10 years ago
}
}
public static void RemoveFileSystemAuditRule(FileSystemInfo item, FileSystemAuditRule ace)
{
if (item is FileInfo)
{
var file = (FileInfo)item;
var sd = file.GetAccessControl(AccessControlSections.Audit);
sd.RemoveAuditRuleSpecific(ace);
fix: write only the sections of the security descriptor that a cmdlet changes The access and audit cmdlets wrote the owner of an item back with the entries they changed. For a DACL without the auto-inherit flag, Windows returns the owner and the group even when only the DACL is read, and the cmdlets wrote every section that the descriptor held. Without the Restore privilege, or on a file server that refuses the owner, the write failed with error 1307 (#34). - Add-NTFSAccess, Clear-NTFSAccess, Add-NTFSAudit, and Clear-NTFSAudit read only the DACL or the SACL. FileSystemSecurity2.Write(), Remove-NTFSAccess, and Remove-NTFSAudit write only the sections they read, which also fixes the access inheritance cmdlets. - Read together with the SACL, the inherited entries of such a DACL lose their inherited flag when the parent folder has no SACL, and the cmdlets stored them as explicit copies. Get-NTFSSecurityDescriptor now reads the DACL in a separate call. - Set-NTFSSecurityDescriptor writes only the sections that changed since they were read; an unchanged descriptor writes nothing (maintainer decision of 2026-10-06). - Clear-NTFSAudit writes nothing for an item without a SACL, and reports an error without the Security privilege (maintainer decision). The regression tests failed before and pass after the fix in Windows PowerShell 5.1 and PowerShell 7, elevated and as a basic user. Co-authored-by: Copilot &lt;223556219+Copilot@users.noreply.github.com&gt; Co-authored-by: AI Assistant &lt;ai@example.com&gt;
4 weeks ago
file.SetAccessControl(sd, AccessControlSections.Audit);
new upload
10 years ago
}
else
{
DirectoryInfo directory = (DirectoryInfo)item;
var sd = directory.GetAccessControl(AccessControlSections.Audit);
sd.RemoveAuditRuleSpecific(ace);
fix: write only the sections of the security descriptor that a cmdlet changes The access and audit cmdlets wrote the owner of an item back with the entries they changed. For a DACL without the auto-inherit flag, Windows returns the owner and the group even when only the DACL is read, and the cmdlets wrote every section that the descriptor held. Without the Restore privilege, or on a file server that refuses the owner, the write failed with error 1307 (#34). - Add-NTFSAccess, Clear-NTFSAccess, Add-NTFSAudit, and Clear-NTFSAudit read only the DACL or the SACL. FileSystemSecurity2.Write(), Remove-NTFSAccess, and Remove-NTFSAudit write only the sections they read, which also fixes the access inheritance cmdlets. - Read together with the SACL, the inherited entries of such a DACL lose their inherited flag when the parent folder has no SACL, and the cmdlets stored them as explicit copies. Get-NTFSSecurityDescriptor now reads the DACL in a separate call. - Set-NTFSSecurityDescriptor writes only the sections that changed since they were read; an unchanged descriptor writes nothing (maintainer decision of 2026-10-06). - Clear-NTFSAudit writes nothing for an item without a SACL, and reports an error without the Security privilege (maintainer decision). The regression tests failed before and pass after the fix in Windows PowerShell 5.1 and PowerShell 7, elevated and as a basic user. Co-authored-by: Copilot &lt;223556219+Copilot@users.noreply.github.com&gt; Co-authored-by: AI Assistant &lt;ai@example.com&gt;
4 weeks ago
directory.SetAccessControl(sd, AccessControlSections.Audit);
new upload
10 years ago
}
}
fix: address review findings for group B Write orphaned audit entries outside the read error handler, so that a stopped pipeline isn&#39;t reported as a read error. Pass -RemoveSpecific through the string path overload of RemoveFileSystemAuditRule, and state on the Get-NTFSSimpleAccess page that the security descriptor of a file is reported. Co-authored-by: Copilot &lt;223556219+Copilot@users.noreply.github.com&gt; Co-authored-by: AI Assistant &lt;ai@example.com&gt;
4 weeks ago
public static void RemoveFileSystemAuditRule(string path, IdentityReference2 account, FileSystemRights2 rights, AuditFlags type, InheritanceFlags inheritanceFlags, PropagationFlags propagationFlags, bool removeSpecific = false)
new upload
10 years ago
{
if (File.Exists(path))
{
var item = new FileInfo(path);
fix: address review findings for group B Write orphaned audit entries outside the read error handler, so that a stopped pipeline isn&#39;t reported as a read error. Pass -RemoveSpecific through the string path overload of RemoveFileSystemAuditRule, and state on the Get-NTFSSimpleAccess page that the security descriptor of a file is reported. Co-authored-by: Copilot &lt;223556219+Copilot@users.noreply.github.com&gt; Co-authored-by: AI Assistant &lt;ai@example.com&gt;
4 weeks ago
RemoveFileSystemAuditRule(item, account, rights, type, inheritanceFlags, propagationFlags, removeSpecific);
new upload
10 years ago
}
else
{
var item = new DirectoryInfo(path);
fix: address review findings for group B Write orphaned audit entries outside the read error handler, so that a stopped pipeline isn&#39;t reported as a read error. Pass -RemoveSpecific through the string path overload of RemoveFileSystemAuditRule, and state on the Get-NTFSSimpleAccess page that the security descriptor of a file is reported. Co-authored-by: Copilot &lt;223556219+Copilot@users.noreply.github.com&gt; Co-authored-by: AI Assistant &lt;ai@example.com&gt;
4 weeks ago
RemoveFileSystemAuditRule(item, account, rights, type, inheritanceFlags, propagationFlags, removeSpecific);
new upload
10 years ago
}
}
public static FileSystemAuditRule2 RemoveFileSystemAuditRule(FileSystemSecurity2 sd, IdentityReference2 account, FileSystemRights2 rights, AuditFlags type, InheritanceFlags inheritanceFlags, PropagationFlags propagationFlags, bool removeSpecific = false)
{
var ace = (FileSystemAuditRule)sd.SecurityDescriptor.AuditRuleFactory(account, (int)rights, false, inheritanceFlags, propagationFlags, type);
if (sd.IsFile)
{
if (removeSpecific)
((FileSecurity)sd.SecurityDescriptor).RemoveAuditRuleSpecific(ace);
else
((FileSecurity)sd.SecurityDescriptor).RemoveAuditRule(ace);
}
else
{
if (removeSpecific)
((DirectorySecurity)sd.SecurityDescriptor).RemoveAuditRuleSpecific(ace);
else
((DirectorySecurity)sd.SecurityDescriptor).RemoveAuditRule(ace);
}
return ace;
}
public static IEnumerable<FileSystemAuditRule2> RemoveFileSystemAuditRule(FileSystemSecurity2 sd, List<IdentityReference2> accounts, FileSystemRights2 rights, AuditFlags type, InheritanceFlags inheritanceFlags, PropagationFlags propagationFlags, bool removeSpecific = false)
{
var aces = new List<FileSystemAuditRule2>();
foreach (var account in accounts)
{
fix: restore -RemoveSpecific in Remove-NTFSAccess and Remove-NTFSAudit Defect 17. Both cmdlets carried a removeSpecific field that no parameter set, so they always took the rights away from matching entries; the version history documents a -RemoveSpecific switch since 4.1. Both cmdlets now have the switch, which removes only an entry that matches exactly. The Security2 list overloads didn&#39;t pass the flag on, and the audit item overload didn&#39;t support it; all overloads now do. The applies-to field of both cmdlets is initialized; -AppliesTo is mandatory in the Simple sets since defect 14, so it is always set when used. Tests: Access.Tests.ps1 3 tests, Audit.Tests.ps1 2 tests, on in-memory security descriptors. Co-authored-by: Copilot &lt;223556219+Copilot@users.noreply.github.com&gt; Co-authored-by: AI Assistant &lt;ai@example.com&gt;
4 weeks ago
aces.Add(RemoveFileSystemAuditRule(sd, account, rights, type, inheritanceFlags, propagationFlags, removeSpecific));
new upload
10 years ago
}
return aces;
}
}
}