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.

73 lines
2.1 KiB

10 years ago
using Alphaleonis.Win32.Filesystem;
using System.Security.AccessControl;
using System.Security.Principal;
namespace Security2
{
public class FileSystemOwner
{
private FileSystemInfo item;
private IdentityReference2 owner;
private FileSystemSecurity sd;
public FileSystemInfo Item
{
get { return item; }
}
public IdentityReference2 Owner
{
get { return owner; }
}
public IdentityReference2 Account
{
get { return owner; }
}
public string FullName
{
fix(security2): let the readers handle a descriptor that has no item 3.1 made a FileSystemSecurity2 without an item reachable from a .NET caller (the conversions from FileSecurity and DirectorySecurity), but six sibling call sites still dereferenced the item without checking it first, so a caller who converted a FileSecurity or DirectorySecurity and then read its entries, owner, inheritance, or effective access met a NullReferenceException instead of a usable result. GetFileSystemAccessRules and GetFileSystemAuditRules (the FileSystemSecurity2 overload) now give each returned entry the same null FullName that the descriptor itself reports; asking for the source of an inherited entry (getInheritedFrom) needs the path of the item, so it now throws one clear InvalidOperationException instead, naming the reason, when the descriptor has none. FileSystemOwner and FileSystemInheritanceInfo give a null FullName (and Name) the same way; FileSystemOwner.ToString, which must never return null, gives an empty string instead, since there is no other representation to fall back to. The FileSystemAccessRule2(rule, item) constructor, which EffectiveAccess.GetEffectiveAccess uses to build its result, now accepts a null item the same way, so effective access can be calculated for such a descriptor and the result names no path. Every existing behavior for an item that is not null is unchanged; only a .NET caller that reads such a descriptor can notice the difference, and only for the better: a usable result or a clear error instead of an unrelated NullReferenceException. Public signatures are unchanged. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: AI Assistant <ai@example.com>
1 week ago
// Null without an item, such as for a descriptor that a conversion from FileSecurity built directly,
// instead of a NullReferenceException.
get { return item != null ? item.FullName : null; }
}
10 years ago
private FileSystemOwner(FileSystemInfo item, IdentityReference2 owner)
{
this.item = item;
this.owner = owner;
}
public static FileSystemOwner GetOwner(FileSystemSecurity2 sd)
{
return new FileSystemOwner(sd.Item, sd.SecurityDescriptor.GetOwner(typeof(SecurityIdentifier)));
}
public static void SetOwner(FileSystemSecurity2 sd, IdentityReference2 account)
{
sd.SecurityDescriptor.SetOwner(account);
}
public static FileSystemOwner GetOwner(FileSystemInfo item)
{
return GetOwner(new FileSystemSecurity2(item, AccessControlSections.Owner));
}
public static void SetOwner(FileSystemInfo item, IdentityReference2 account)
{
var sd = new FileSystemSecurity2(item, AccessControlSections.Owner);
SetOwner(sd, account);
sd.Write();
}
public override string ToString()
{
fix(security2): let the readers handle a descriptor that has no item 3.1 made a FileSystemSecurity2 without an item reachable from a .NET caller (the conversions from FileSecurity and DirectorySecurity), but six sibling call sites still dereferenced the item without checking it first, so a caller who converted a FileSecurity or DirectorySecurity and then read its entries, owner, inheritance, or effective access met a NullReferenceException instead of a usable result. GetFileSystemAccessRules and GetFileSystemAuditRules (the FileSystemSecurity2 overload) now give each returned entry the same null FullName that the descriptor itself reports; asking for the source of an inherited entry (getInheritedFrom) needs the path of the item, so it now throws one clear InvalidOperationException instead, naming the reason, when the descriptor has none. FileSystemOwner and FileSystemInheritanceInfo give a null FullName (and Name) the same way; FileSystemOwner.ToString, which must never return null, gives an empty string instead, since there is no other representation to fall back to. The FileSystemAccessRule2(rule, item) constructor, which EffectiveAccess.GetEffectiveAccess uses to build its result, now accepts a null item the same way, so effective access can be calculated for such a descriptor and the result names no path. Every existing behavior for an item that is not null is unchanged; only a .NET caller that reads such a descriptor can notice the difference, and only for the better: a usable result or a clear error instead of an unrelated NullReferenceException. Public signatures are unchanged. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: AI Assistant <ai@example.com>
1 week ago
// Empty, not null, without an item: ToString must never return null, and there is no other
// representation of this object to fall back to.
return item != null ? item.FullName : string.Empty;
10 years ago
}
}
}