因此,我尝试修改BUILTIN \ Users组的权限,以至少具有修改文件系统访问权限。不幸的是,我尝试使用下面的代码会产生不变的ACL。
SecurityIdentifier usersSecurityIdentifier = ntAccount.Translate(typeof(SecurityIdentifier)) as SecurityIdentifier;
DirectorySecurity directorySecurity = Directory.GetAccessControl(source.FullName);
FileSystemAccessRule accessRule
= new FileSystemAccessRule(@"BUILTIN\Users", FileSystemRights.FullControl, AccessControlType.Allow);
directorySecurity.ModifyAccessRule(AccessControlModification.Add,
accessRule,
out modified);
Console.WriteLine(modified);
修改后的报告在每种情况下均为true,但是当您在文件夹属性上查看时,perms不会更新。
我还尝试为一个SecurityIdentifier添加一个访问规则,该规则使用类似的代码而不是已经拥有该目录的ACL,而只是AddAccessRule而不是modify。即使新的SecurityIdentifier出现在目录的perms列表中,它们也没有我指定的访问权限。
我正在尝试修改管理员帐户所属的Environment.SpecialFolders.CommonApplicationData中的专有目录的访问权限。我也在考虑以管理员身份修改ACL。
有没有人知道上面的代码有什么问题,或者是否有任何资源可以引导我使用本机.NET类本机设置ACL的正确方法?
答案 0 :(得分:3)
我在一位在微软工作的朋友的帮助下想到了这一点。实际上,我用来设置ACL的过程是准确的。我错误地解释了结果。基本上,只要您在尝试进行更改时以管理员身份运行,就可以通过这种方式在目录上设置ACL。
该文件夹的准确权限可通过以下方式查看(在Vista中):
这是我失踪的部分。 CommonApplicationData路径已经为BUILTIN \ Users实体设置了权限。因此,在运行我的代码之后,我实际上最终得到了两个实体。有人说Read&执行,另一个说特殊权限。当我编辑具有特殊权限的实体时,我实际上看到BUILTIN \ Users确实可以访问该目录。
我真的在寻找BUILTIN \ Users来访问该目录及其所有子文件夹和对象。这是我最终使用的代码片段。我能够通过测试工具确认我的代码,并手动检查文件和目录ACL列表。
DirectorySecurity directorySecurity = Directory.GetAccessControl(Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData));
FileSystemAccessRule accessRule
= new FileSystemAccessRule(@"BUILTIN\Users", FileSystemRights.FullControl,
InheritanceFlags.ObjectInherit | InheritanceFlags.ContainerInherit,
PropagationFlags.None,
AccessControlType.Allow);
bool modified=false;
directorySecurity.ModifyAccessRule(AccessControlModification.Add,
accessRule,
out modified);
if (modified)
{
source.Create(directorySecurity);
}
else
{
source.Create();
}