|
|
|
|
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; }
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
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;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|