harmony 鸿蒙Development on IPC Authentication

2022-08-09
浏览 (588)

Development on IPC Authentication

When to Use

System services registered with Samgr can be accessed by other processes through IPC APIs. When a process requests to access such an API, IPC authentication is triggered to check whether the process has the required permission. If the process does not have the required permission, the access request will be denied.

When developing a system service, you can use the IPC authentication component to configure access policies for APIs of the service. When other services access these APIs through IPC, Samgr calls APIs of the IPC authentication component to check whether the services have the access permission.

Available APIs

The following table lists the APIs provided by IPC authentication (intended for Samgr only).

Table 1 APIs provided by IPC authentication

Function	Description
int GetCommunicationStrategy(RegParams params, PolicyTrans *policies, unsigned int policyNum)	Obtains the access policies of a service API.
int IsCommunicationAllowed(AuthParams params)	Checks whether a process has the permission to access an API of another process.

How to Develop

This section uses BMS as an example to describe how to configure access policies for APIs provided by the IPC authentication component. In this example, the service registered by BMS with Samgr is bundlems, and the feature registered for open APIs is BmsFeature.

On the OpenHarmony side, configure access policies in the base/security/permission/services/permission_lite/ipc_auth/include/policy_preset.h file. On the device side, configure access policies in the vendor/hisilicon/product name/hals/security/permission_lite/ipc_auth/include/policy_preset_product.h file. After that, set POLICY_PRODUCT in the header files to 1. Access policies are classified into the following three types:

RANGE: Processes with a specified range of UIDs can access BMS APIs. uidMin and uidMax must be specified.
FIXED: Processes with specified UIDs can access BMS APIs. fixedUid must be specified, and a maximum of eight UIDs are allowed.
BUNDLENAME: An application with a specified bundleName can access BMS APIs.

FeaturePolicy bmsFeature[] = {
    {
        "BmsFeature",
        {
            {
                .type=FIXED,    // Processes with specified UIDs can access BMS APIs.
                .fixedUid={2, 3, 8}
            },
            {
                .type=RANGE,    // Processes with a specified range of UIDs can access BMS APIs. 
                .uidMin=100,
                .uidMax=__INT_MAX__,
            },
        }
    },
    {
        "BmsInnerFeature",
        {
            {
                .type=FIXED,     // Processes with specified UIDs can access BMS APIs.
                .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},  // Add the policies configured for the two features in [Step 1](#li15901515152517) to the global policy settings.
    {"dtbschedsrv", dmsFeature, 1},
    {"samgr", samgrFeature, 1},
    {"appspawn", appspawnFeature, 1},
    {"WMS", wmsFeature, 1},
    {"bundle_daemon", bdsFeature, 1},
};

const char BMS_SERVICE[] = "bundlems";
const char BMS_FEATURE[] = "BmsFeature";
static void Init()
{
    SamgrLite *sm = SAMGR_GetInstance();
    if (sm == nullptr) {
        return;
    }
    // Register the BmsFeature 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 you register a service with Samgr, Samgr calls the GetCommunicationStrategy function of the IPC authentication component to obtain access policies of the service. When other services or applications access this service through IPC, Samgr calls the IsCommunicationAllowed function of the IPC authentication component to check whether the services or applications have the access permission.

FAQ

Registering a service with Samgr failed

Problem

During the startup of a new service, a message is displayed indicating that the service fails to be registered with Samgr.

Cause

The service UID is not configured in the IPC authentication component.

Solution

Configure a valid UID for the service in the base/security/permission/services/permission_lite/ipc_auth/src/ipc_auth_impl.c file.