Fetch the repository succeeded.
This action will force synchronization from OpenHarmony/security_permission_lite, which will overwrite any changes that you have made since you forked the repository, and can not be recovered!!!
Synchronous operation will process in the background and will refresh the page when finishing processing. Please be patient.
In OpenHarmony, apps and system services run in independent sandboxes. Both processes and data are isolated from each other to protect the security of app data. However, services or apps running in the sandboxes provide some APIs to implement specific functionalities. To access these APIs across processes, apps in other sandboxes need the required permissions, which are granted and managed based on a permission management mechanism.
App permission management provides the following features:
Provides a mechanism for defining permissions, allowing system services and apps to define new permissions for their sensitive APIs. To access these APIs, other apps need the required permissions.
Allows apps to request permissions defined by the system or other applications. Upon obtaining the permissions, the apps can access the sensitive APIs provided by the system or other apps.
Allows users to view and manage the permission granting status.
Figure 1 App permission management architecture
App permission management provides permission management for the app framework subsystem and provides APIs for apps to request permissions and query the permission granting status. The open-source app permission management applies to mini and small systems.
/base/security/permission_lite
├── interfaces # APIs
│ ├── innerkits # Internal APIs
│ └── kits # External APIs
└── services # Services
├── ipc_auth # IPC communication authentication
├── js_api # JS API encapsulation
├── pms # Permission management logic and server
├── pms_base # Service registration
└── pms_client # Permission management client
The APIs for app permission management of the mini and small systems can be called only by system apps and services. The following table describes the APIs.
| API | Description |
|---|---|
| int CheckPermission(int uid, const char *permissionName) | Checks whether an app has the permission to access system service APIs. |
| int CheckSelfPermission(const char *permissionName) | Checks whether the caller has the permission to access system service APIs. |
| int QueryPermission(const char *identifier, PermissionSaved **permissions, int *permNum) | Queries all permissions requested by an app and checks whether the requested permissions have been granted. |
| int GrantPermission(const char *identifier, const char *permName) | Grants a permission to an app. |
| int RevokePermission(const char *identifier, const char *permName) | Revokes a permission from an app. |
| int GrantRuntimePermission(int uid, const char *permissionName) | Grants a permission during the running of an app. |
| int RevokeRuntimePermission(int uid, const char *permissionName) | Revokes a permission during the running of an app. |
| int UpdatePermissionFlags(const char *identifier, const char *permissionName, const int flags) | Updates the flags of the permission specified by an app. |
The following table describes the APIs for IPC authentication of the mini and small systems.
| API | Description |
|---|---|
| int GetCommunicationStrategy(RegParams params, PolicyTrans **policies, unsigned int *policyNum) | Obtains the access policies for a service API. This API can be called only by System Ability Manager (SAMGR). |
| int IsCommunicationAllowed(AuthParams params) | Checks whether a process has the permission to access an API of another process. This API can be called only by SAMGR. |
App Permission Management for a Mini or Small System
The following uses the app permission development of the bundle manager service (BMS) as an example. Declare the required sensitive permissions in the config.json file during development. During app installation, the BMS calls APIs of the app permission management component to check whether the required permissions are available. If yes, the installation proceeds; otherwise, the installation fails.
During development, determine and declare the permission (ohos.permission.INSTALL_BUNDLE) required for installing the app. If the FA model is used, declare the permission in the config.json file. The following is an example:
{
"module": {
"package": "ohos.demo.kitframework",
"deviceType": [
"phone", "tv","tablet", "car","smartWatch","sportsWatch","smartCamera", "smartVision"
],
"reqPermissions": [{
"name": "ohos.permission.INSTALL_BUNDLE",
"reason": "install bundle",
"usedScene": {
"ability": [
"KitFramework"
],
"when": "always"
}
},
{
"name": "ohos.permission.LISTEN_BUNDLE_CHANGE",
"reason": "install bundle",
"usedScene": {
"ability": [
"KitFramework"
],
"when": "always"
}
},
{
"name": "ohos.permission.GET_BUNDLE_INFO",
"reason": "install bundle",
"usedScene": {
"ability": [
"KitFramework"
],
"when": "always"
}
}
]
}
}
If the stage model is used, declare the permission in module.json5. The following is an example:
{
"module": {
"requestPermissions": [{
"name": "ohos.permission.INSTALL_BUNDLE",
"reason": "install bundle",
"usedScene": {
"ability": [
"KitFramework"
],
"when": "always"
}
},
{
"name": "ohos.permission.LISTEN_BUNDLE_CHANGE",
"reason": "install bundle",
"usedScene": {
"ability": [
"KitFramework"
],
"when": "always"
}
},
{
"name": "ohos.permission.GET_BUNDLE_INFO",
"reason": "install bundle",
"usedScene": {
"ability": [
"KitFramework"
],
"when": "always"
}
}]
}
}
When developing the app installation API, use the CheckPermission() API to check whether the BMS has the permission to install the application. For example, CheckPermission() is called with the permission name ohos.permission.INSTALL_BUNDLE as the input parameter to check whether the BMS has the permission to install the app. If the BMS has the permission, the installation continues. Otherwise, the installation fails.
constexpr static char PERMISSION_INSTALL_BUNDLE[] = "ohos.permission.INSTALL_BUNDLE";
bool Install(const char *hapPath, const InstallParam *installParam, InstallerCallback installerCallback)
{
if ((hapPath == nullptr) || (installerCallback == nullptr) || (installParam == nullptr)) {
HILOG_ERROR(HILOG_MODULE_APP, "BundleManager install failed due to nullptr parameters");
return false;
}
// Check whether the ohos.permission.INSTALL_BUNDLE permission has been granted.
if (CheckPermission(0, static_cast<const char *>(PERMISSION_INSTALL_BUNDLE)) != GRANTED) {
HILOG_ERROR(HILOG_MODULE_APP, "BundleManager install failed due to permission denied");
return false; // App installation fails.
}
// Installation process.
...
}
IPC Authentication for a Mini or Small System
The following example describes how to use the IPC authentication component to configure the policies for accessing the BMS feature. In this example, the service registered by the BMS with SAMGR is bundlems, and the feature registered is BmsFeature.
Configure the access policy in the header file base/security/permission_lite/services/ipc_auth/include/policy_preset.h in the source code directory. There are three types of access policies:
FeaturePolicy bmsFeature[] = {
{
"BmsFeature",
{
{
.type=FIXED, // Allow access from the processes with the specified UIDs.
.fixedUid={2, 3, 8}
},
{
.type=RANGE, // Allow access from the processes with UIDs in the specified range.
.uidMin=100,
.uidMax=__INT_MAX__,
},
}
},
{
"BmsInnerFeature",
{
{
.type=FIXED, // Allow access from the processes with the specified UIDs.
.fixedUid={2, 3, 8}
},
{
.type=RANGE,
.uidMin=100,
.uidMax=999,
},
}
},
};
Add the policies configured for the features in Step 1 to the global policy settings. You need to set the number of features.
static PolicySetting g_presetPolicies[] = {
{"permissionms", pmsFeature, 1},
{"abilityms", amsFeature, 2},
{"bundlems", bmsFeature, 2}, // BMS feature defined in step 1. The number of BMS features is 2.
{"dtbschedsrv", dmsFeature, 1},
{"samgr", samgrFeature, 1},
{"appspawn", appspawnFeature, 1},
{"WMS", wmsFeature, 1},
{"bundle_daemon", bdsFeature, 1},
};
Register the BmsFeature defined in Step 1 with SAMGR.
const char BMS_SERVICE[] = "bundlems";
const char BMS_FEATURE[] = "BmsFeature";
static void Init()
{
SamgrLite *sm = SAMGR_GetInstance();
if (sm == nullptr) {
return;
}
// Register the service with SAMGR.
sm->RegisterFeature(BMS_SERVICE, reinterpret_cast<Feature *>(BundleMsFeature::GetInstance()));
sm->RegisterFeatureApi(BMS_SERVICE, BMS_FEATURE,
GetBmsFeatureApi(reinterpret_cast<Feature *>(BundleMsFeature::GetInstance())));
HILOG_DEBUG(HILOG_MODULE_APP, "BundleMS feature start success");
}
APP_FEATURE_INIT(Init);
When the specified services are registered with SAMGR, SAMGR calls GetCommunicationStrategy() of the IPC authentication component to obtain the access policy for the services. When other services or apps access these services over IPC, SAMGR calls IsCommunicationAllowed() of the IPC authentication component to check the permission of the caller service. If the access policy is met, the access is allowed. Otherwise, the access is rejected.
Security subsystem
此处可能存在不合适展示的内容，页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容，可点击提交进行申诉，我们将尽快为您处理。
马建仓 AI 助手