《The Custom Permission Problem》部分译文

本文探讨了Android中自定义权限的潜在风险,特别是当多个应用程序定义相同权限时可能导致的问题。通过具体场景展示了不同应用如何定义和使用同一权限,并讨论了用户在安装应用时可能遇到的情况。
自定义用户权限问题


从一开始Android便提供了系统权限(由原生框架定义)和用户自定义权限(由应用定义).


不幸的是,自定义权限有一些“无证的局限性”使得它们存在内在的风险.特别地,自定义权限可能被任何人,任何时间,被定义,而且“先定义的权限为王”(原文:“first one in wins”),这些可能引发一些意外的行为.


在这里,我们将介绍一些场景并展示一些可能存在风险的问题,附带我们最好能做些什么来缓解这些问题.


情境


下面所有的场景都集中在3个主要的应用工程文件.


应用A定义了一个自定义的权限在他的manifest文件中,如:


<permission
    android:name="com.commonsware.cwac.security.demo.OMG"
    android:description="@string/perm_desc"
    android:label="@string/perm_label"
    android:protectionLevel="normal"/>


应用A也使用了“android:permission”属性并引用了这个权限来保护了一个组件:


<provider
    android:name="FileProvider"
    android:authorities="com.commonsware.cwac.security.demo.files"
    android:exported="true"
    android:grantUriPermissions="false"
    android:permission="com.commonsware.cwac.security.demo.OMG">
    <grant-uri-permission android:path="/test.pdf"/>
</provider>


应用B申明了一个这个权限,以此来获取被这个权限保护的组件使用权:
<uses-permission android:name="com.commonsware.cwac.security.demo.OMG"/>


应用C同样的申明了这个权限.区别在于应用B也有定义<permission>元素,正如应用A所做的,只不过有不同的描述信息(如:android:descriptioin)、不同的保护级别.


以上三个应用都是使用不同的签名key来生成APK的,因为现实时间里它们是来自于不同的开发者.


好,扼要重述一下:


应用A定义了一个permission并使用它来保护一个组件.


应用B定义了同样的一个权限并请求获取到它.


应用C仅仅获取了这个权限.


把这些都放到脑海之中,让我们走入一些可能的场景,同时集中思考下面两个问题:


1、当应用通过正常的方式(如:不是用命令“adb”)安装时,关于这个权限,用户能被告知什么?


2、若是存在应用A或B不得不通过应用A的“ContentProvider”获取数据的情况,又会怎样?


原文地址:https://github.com/commonsguy/cwac-security/blob/master/PERMS.md

多源动态最优潮流的分布鲁棒优化方法(IEEE118节点)(Matlab代码实现)内容概要:本文介绍了基于Matlab代码实现的多源动态最优潮流的分布鲁棒优化方法,适用于IEEE118节点电力系统。该方法结合两阶段鲁棒模型与确定性模型,旨在应对电力系统中多源输入(如可再生能源)的不确定性,提升系统运行的安全性与经济性。文中详细阐述了分布鲁棒优化的建模思路,包括不确定性集合的构建、目标函数的设计以及约束条件的处理,并通过Matlab编程实现算法求解,提供了完整的仿真流程与结果分析。此外,文档还列举了大量相关电力系统优化研究案例,涵盖微电网调度、电动汽车集群并网、需求响应、储能配置等多个方向,展示了其在实际工程中的广泛应用价值。; 适合人群:具备一定电力系统基础知识和Matlab编程能力的研究生、科研人员及从事能源系统优化工作的工程师。; 使用场景及目标:①用于研究高比例可再生能源接入背景下电力系统的动态最优潮流问题;②支撑科研工作中对分布鲁棒优化模型的复现与改进;③为电力系统调度、规划及运行决策提供理论支持与仿真工具。; 阅读建议:建议读者结合提供的Matlab代码与IEEE118节点系统参数进行实操演练,深入理解分布鲁棒优化的建模逻辑与求解过程,同时可参考文中提及的其他优化案例拓展研究思路。
在 Android 开发中,自定义权限(Custom Permissions)的声明需要特别注意命名规则,尤其是避免与系统权限或 Android SDK 中已保留的命名空间发生冲突。如果自定义权限的名称或前缀与系统或 SDK 中保留的关键字、命名空间重复,可能导致权限声明无效、运行时异常,甚至安全漏洞。 Android 要求所有自定义权限的命名必须遵循以下规则: - 自定义权限的名称必须以应用的包名为前缀,确保唯一性,例如 `com.example.myapp.permission.CUSTOM_PERMISSION`。 - 不得使用 `android.permission` 或 `com.android` 等系统保留的命名空间,否则系统会忽略该权限或抛出异常 [^4]。 - 避免使用与 Android SDK 中已有权限名称相同的字符串,例如 `READ_CONTACTS`、`INTERNET` 等。 如果开发者在 `AndroidManifest.xml` 中声明了与系统权限同名的自定义权限,系统将忽略该声明,这可能导致应用在请求该权限时出现不可预料的行为。此外,使用系统保留的前缀(如 `android.permission`)可能会导致应用在安装或运行时被拒绝执行,具体取决于 Android 版本和设备厂商的实现 [^5]。 为确保自定义权限不会与系统或 SDK 权限发生冲突,建议采取以下最佳实践: 1. 使用应用的包名作为权限名称的前缀。 2. 在声明权限前,查阅 Android 官方文档,确认所使用的权限名称未被系统或 SDK 占用。 3. 使用工具如 `aapt` 或构建时检查机制,验证是否存在命名冲突。 示例代码如下,展示如何在 `AndroidManifest.xml` 中正确声明一个自定义权限: ```xml <permission android:name="com.example.myapp.permission.ACCESS_SENSORS" android:label="Access Sensors" android:description="Allows the app to access sensor data." android:protectionLevel="normal" /> ``` 在代码中请求该权限的方式如下: ```java if (ContextCompat.checkSelfPermission(context, "com.example.myapp.permission.ACCESS_SENSORS") != PackageManager.PERMISSION_GRANTED) { ActivityCompat.requestPermissions(activity, new String[]{"com.example.myapp.permission.ACCESS_SENSORS"}, REQUEST_CODE); } ``` 若检测到命名冲突,可以使用 Android Lint 工具进行静态分析,识别潜在的命名问题。此外,构建流程中可以集成自动化脚本,扫描所有权限声明并比对系统权限列表,提前发现冲突。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值