寻找在 Sandbox AppDomain 中加载程序集的最低权限。为什么需要这些权限?
我正在尝试为沙箱 AppDomain 设置最低权限,以便加载程序集。似乎必须对 appBase 具有 PathDiscovery 权限,对加载的程序集具有 Read 权限,但对依赖程序集不需要任何权限。我的问题是: 为什么我们需要路径发现?对每个所需的程序集的读取访问权限还不够吗? 为什么只有加载的程序集需要读取权限,而不是依赖的程序集?
这里有一个代码片段来提供一些上下文:
AppDomainSetup setup = new AppDomainSetup
{
ApplicationName = "Name",
ApplicationBase = binFolder,
};
PermissionSet permissionSet = new PermissionSet(PermissionState.None);
permissionSet.AddPermission(new SecurityPermission(SecurityPermissionFlag.Execution));
// Mandatory. Why PathDiscovery is needed?
permissionSet.AddPermission(new FileIOPermission(FileIOPermissionAccess.PathDiscovery, binFolder));
// Mandatory. Why Read is not also needed for all dependent assemblies?
permissionSet.AddPermission(new FileIOPermission(FileIOPermissionAccess.Read, assemblyPath));
var domain = AppDomain.CreateDomain("Domain Name", null, setup, permissionSet);
domain.CreateInstanceFromAndUnwrap(assemblyPath, typeName);
I'm trying to put in place the minimum permissions for a sandbox AppDomain in order to load an assembly. It seems that it is mandatory to have PathDiscovery permission on the appBase and Read permission on the loaded assembly, but no permission is required on the dependent assemblies. My questions are:
Why do we need PathDiscovery? isn't read access enough on each needed assembly?
Why only the loaded assembly needs Read permission and not the dependent ones?
Here a code snippet to give some context:
AppDomainSetup setup = new AppDomainSetup
{
ApplicationName = "Name",
ApplicationBase = binFolder,
};
PermissionSet permissionSet = new PermissionSet(PermissionState.None);
permissionSet.AddPermission(new SecurityPermission(SecurityPermissionFlag.Execution));
// Mandatory. Why PathDiscovery is needed?
permissionSet.AddPermission(new FileIOPermission(FileIOPermissionAccess.PathDiscovery, binFolder));
// Mandatory. Why Read is not also needed for all dependent assemblies?
permissionSet.AddPermission(new FileIOPermission(FileIOPermissionAccess.Read, assemblyPath));
var domain = AppDomain.CreateDomain("Domain Name", null, setup, permissionSet);
domain.CreateInstanceFromAndUnwrap(assemblyPath, typeName);
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
因为从指定路径成功加载程序集将表明该路径存在。同样,尝试从路径加载程序集时引发的某些异常也会表明该路径有效,即使目标文件不是 .NET 程序集。
由于加载的程序集不控制加载其依赖项的位置,因此仅能够加载依赖项程序集并不会透露有关特定路径有效性的信息。也就是说,它确实揭示了一些信息,因为 .NET 程序集搜索位置是众所周知的,所以我想可以说这里的检查应该更强一些。如果您对此有强烈的感觉,可以在 https://connect.microsoft.com/visualstudio 发布错误报告/反馈。
Because successfully loading an assembly from a specified path would reveal that the path exists. Similarly, certain exceptions thrown from an attempt to load an assembly from a path would also reveal that the path is valid, even if the target file is not a .NET assembly.
Because the loaded assembly does not control the locations from which its dependencies are loaded, so simply being able to load a dependent assembly does not reveal information about the validity of a specific path. That said, it does reveal some information since the .NET assembly search locations are well known, so I suppose it could be argued that the check here should be a bit stronger. If you feel strongly about it, you could post a bug report at https://connect.microsoft.com/visualstudio/feedback.