Управление разрешениями приложений

/base/security/permission_lite
├── interfaces                         # Слой интерфейсов
│   ├── innerkits                      # Внутренний слой интерфейсов
│   └── kits                           # Внешний слой интерфейсов
└── services                           # Слой сервисов
    ├── ipc_auth                       # IPC-коммуникационная аутентификация
    ├── js_api                         # Упаковка JS API
    ├── pms                            # Логика управления правами и сервисы
    ├── pms_base                       # Регистрация сервисов
    └── pms_client                     # Клиентская часть сервиса управления правами

     "module": {
        "requestPermissions": [{
          "name": "ohos. permission. INSTALL_BUNDLE",
          "reason": "установка пакета",
          "usedScene": {
            "ability": [
              "KitFramework"
            ],
            "when": "always"
          }
        },
        {
          "name": "ohos. permission. LISTEN_BUNDLE_CHANGE",
          "reason": "установка пакета",
          "usedScene": {
            "ability": [
              "KitFramework"
            ],
            "when": "always"
          }
        },
        {
          "name": "ohos. permission. GET_BUNDLE_INFO",
          "reason": "установка пакета",
          "usedScene": {
            "ability": [
              "KitFramework"
            ],
            "when": "always"
          }
        }]
      }
    }
    ```2. Когда пакетный менеджер разрабатывает интерфейсы для установки приложений, он вызывает соответствующие интерфейсы управления правами для проверки наличия прав на установку приложений. Например, он вызывает интерфейс CheckPermission с именем права "ohos. permission. INSTALL_BUNDLE" в качестве параметра для проверки наличия прав на установку пакетного менеджера. Если права есть, процесс установки продолжается, в противном случае возвращается сообщение об ошибке установки.    ```c++
    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;
        }
        // Проверка наличия прав "ohos.permission.INSTALL_BUNDLE"
        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;  // Возвращение ошибки установки
        }
        // Процесс установки
        ...
    }
    ```

**Аутентификация IPC-коммуникаций для легких и малых систем**:

Использование: В качестве примера рассмотрим, как через компонент аутентификации IPC-коммуникаций настраиваются соответствующие политики доступа для открытых интерфейсов BMS-сервиса, использующего метод IPC-коммуникаций. Здесь BMS регистрируется в Samgr как сервис bundlems, а открытые интерфейсы регистрируются как BmsFeature.

1. В файле policy_preset.h, расположенном в заголовках базовых файлов безопасности в директории base/security/permission_lite/services/ipc_auth/include, настраиваются соответствующие политики доступа. Основные типы политик доступа:

    (1) Тип RANGE: разрешает доступ для процессов с определенным диапазоном UID, требуется указать uidMin и uidMax;

    (2) Тип FIXED: разрешает доступ для процессов с определенными UID, требуется указать fixedUid, максимум 8 значений;    (3) Тип BUNDLENAME: разрешает доступ только для определенных приложений, требуется указать bundleName (имя пакета).

    ```c++
    FeaturePolicy bmsFeature[] = {
        {
            "BmsFeature",
            {
                {
                    .type=FIXED,    // Разрешает доступ для процессов с указанными UID
                    .fixedUid={2, 3, 8}
                },
                {
                    .type=RANGE,    // Разрешает доступ для процессов с UID в определённом диапазоне
                    .uidMin=100,
                    .uidMax=__INT_MAX__,
                },
            }
        },
        {
            "BmsInnerFeature",
            {
                {
                    .type=FIXED,     // Разрешает доступ для процессов с указанными UID
                    .fixedUid={2, 3, 8}
                },
                {
                    .type=RANGE,
                    .uidMin=100,
                    .uidMax=999,
                },
            }
        },
    };
    ```

2. Добавьте политику для функции Feature, определенной в шаге 1, в глобальную политику, указав количество функций:

    ```c++
    static PolicySetting g_presetPolicies[] = {
        {"permissionms", pmsFeature, 1},
        {"abilityms", amsFeature, 2},
        {"bundlems", bmsFeature, 2},  // Функция BMS, определенная в шаге 1, количество функций равно 2
        {"dtbschedsrv", dmsFeature, 1},
        {"samgr", samgrFeature, 1},
        {"appspawn", appspawnFeature, 1},
        {"WMS", wmsFeature, 1},
        {"bundle_daemon", bdsFeature, 1},
    };
    ```

3. Зарегистрируйте BmsFeature, определенную в шаге 1, в Samgr:    ```c++
    const char BMS_SERVICE[] = "bundlems";
    const char BMS_FEATURE[] = "BmsFeature";
    static void Init()
    {
        SamgrLite *sm = SAMGR_GetInstance();
        if (sm == nullptr) {
            return;
        }
        // Регистрация службы в 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 функция запущена успешно");
    }
    APP_FEATURE_INIT(Init);
    ```После выполнения вышеуказанных разработочных шагов, при регистрации службы в Samgr, Samgr будет использовать интерфейс GetCommunicationStrategy компонента IPC-коммуникационной аутентификации для получения политики доступа к службе. Когда другие службы или приложения обращаются к этим службам посредством IPC, Samgr будет использовать интерфейс IsCommunicationAllowed компонента IPC-коммуникационной аутентификации для проверки разрешений службы вызывающего. Если разрешения соответствуют политике доступа, вызывающая служба сможет получить доступ к интерфейсу разработчика, в противном случае доступ будет отклонён.

## Связанные репозитории<a name="section1371113476307"></a>
Подсистема безопасности
**[security_permission_lite](https://gitee.com/openharmony/security_permission_lite/blob/master/README_zh.md)**