Объекты файловой системы и службы, добавляемые в сборку, часто требуют отдельных уникальных идентификаторов, известных как идентификаторы Android (AID). В настоящее время многие ресурсы, такие как файлы и службы, используют базовые (определяемые Android) AID без необходимости; во многих случаях вместо них можно использовать AID OEM (определяемые OEM).
В более ранних версиях Android (Android 7.x и ниже) механизм идентификаторов AID был расширен с помощью специфичного для устройства файла android_filesystem_config.h для указания возможностей файловой системы и/или пользовательских идентификаторов OEM AID. Однако эта система была неинтуитивной, поскольку не поддерживала использование удобных имён для идентификаторов OEM AID, требуя указания исходных числовых значений для полей пользователя и группы без возможности связать понятное имя с числовым AID.
Новые версии Android (Android 8.0 и выше) поддерживают новый метод расширения возможностей файловой системы. Этот метод поддерживает следующее:
- Несколько исходных расположений для файлов конфигурации (обеспечивает расширяемые конфигурации сборки).
- Проверка корректности значений OEM AID во время сборки.
- Генерация пользовательского заголовка OEM AID, который можно использовать в исходных файлах по мере необходимости.
- Связь понятного имени с фактическим значением OEM AID. Поддерживает нечисловые строковые аргументы для пользователя и группы, например, «foo» вместо «2901».
Среди дополнительных улучшений — удаление массива android_ids[] из system/core/libcutils/include/private/android_filesystem_config.h . Теперь этот массив существует в Bionic как полностью приватный генерируемый массив с методами доступа getpwnam() и getgrnam() . (Это имеет побочный эффект в виде создания стабильных двоичных файлов при изменении основных AID.) Инструментарий и файл README с более подробной информацией можно найти в build/make/tools/fs_config .
Добавить Android ID (AID)
В Android 8.0 массив android_ids[] был удалён из проекта Android Open Source Project (AOSP). Все имена, совместимые с AID, генерируются из заголовочного файла system/core/libcutils/include/private/android_filesystem_config.h при формировании массива Bionic android_ids[] . Любое define , соответствующее AID_* подхватывается инструментом, и * становится именем в нижнем регистре.
Например, в private/android_filesystem_config.h :
#define AID_SYSTEM 1000Становится:
- Дружественное имя: система
- uid: 1000
- gid: 1000
Чтобы добавить новый основной AID AOSP, просто добавьте директиву #define в заголовочный файл android_filesystem_config.h . AID генерируется при сборке и становится доступен интерфейсам, использующим аргументы пользователя и группы. Инструмент проверяет, не находится ли новый AID в диапазонах APP или OEM; он также учитывает изменения в этих диапазонах и должен автоматически перенастраиваться при изменении или появлении новых зарезервированных OEM диапазонов.
Настроить AID
Чтобы включить новый механизм AID, установите TARGET_FS_CONFIG_GEN в файле BoardConfig.mk . Эта переменная содержит список файлов конфигурации, позволяя добавлять их по мере необходимости.
По соглашению файлы конфигурации используют имя config.fs , но на практике можно использовать любое имя. Файлы config.fs имеют формат ini Python ConfigParser и включают раздел caps (для настройки возможностей файловой системы) и раздел AIDs (для настройки OEM AID).
Настройте раздел «Заголовки»
Раздел caps поддерживает настройку возможностей файловой системы для объектов файловой системы в сборке (сама файловая система также должна поддерживать эту функциональность).
Поскольку запуск стабильной службы от имени root в Android приводит к сбою в тесте совместимости (CTS) , предыдущие требования для сохранения возможностей при запуске процесса или службы включали настройку возможностей с последующим использованием setuid / setgid для правильного AID для запуска. С помощью caps вы можете пропустить эти требования и доверить это ядру. Когда управление передается в main() , ваш процесс уже имеет необходимые возможности, поэтому ваша служба может использовать пользователя и группу, не являющиеся root (это предпочтительный способ запуска привилегированных служб).
В разделе caps используется следующий синтаксис:
| Раздел | Ценить | Определение |
|---|---|---|
[path] | Путь к файловой системе, который нужно настроить. Путь, заканчивающийся на /, считается каталогом, в противном случае это файл. Указание нескольких разделов с одинаковым [path] в разных файлах является ошибкой. В версиях Python <= 3.2 один и тот же файл может содержать разделы, переопределяющие предыдущий; в Python 3.2 для него установлен строгий режим. | |
mode | Восьмеричный режим файла | Допустимый восьмеричный режим файла, состоящий как минимум из трёх цифр. Если указано значение 3, к нему добавляется префикс 0, в противном случае режим используется как есть. |
user | AID_<пользователь> | Либо define C для допустимого AID, либо понятное имя (например, допустимы как AID_RADIO , так и radio ). Чтобы определить собственный AID, см. раздел «Настройка AID» . |
group | AID_<группа> | То же, что и у пользователя. |
caps | кепка* | Имя, объявленное в bionic/libc/kernel/uapi/linux/capability.h без префикса CAP_ в начале. Допускается смешанный регистр. Заглавные буквы также могут быть в исходном виде:
|
Пример использования см. в разделе Использование возможностей файловой системы .
Настройте раздел AID
Раздел AID содержит OEM AID и использует следующий синтаксис:
| Раздел | Ценить | Определение |
|---|---|---|
[AID_<name>] | Имя <name> может содержать символы в верхнем регистре, цифры и символы подчёркивания. В качестве понятного имени используется строчная версия. В сгенерированном заголовочном файле для включения кода используется точное имя AID_<name> .Указание нескольких разделов с одинаковым AID_<name> является ошибкой (без учета регистра и с теми же ограничениями, что и для [path] ).<name> должно начинаться с имени раздела, чтобы исключить конфликты с различными источниками. | |
value | <номер> | Допустимая числовая строка в стиле C (шестнадцатеричная, восьмеричная, двоичная и десятичная). Указывать несколько разделов с одним и тем же значением параметра является ошибкой. Параметры значений должны быть указаны в диапазоне, соответствующем разделу, используемому в <name> . Список допустимых разделов и соответствующих им диапазонов определен в system/core/libcutils/include/private/android_filesystem_config.h . Параметры следующие:
|
Примеры использования см. в разделах Определение имен OEM AID и Использование OEM AID .
Примеры использования
В следующих примерах подробно описано, как определить и использовать OEM AID, а также как включить возможности файловой системы. Имена OEM AID ( [ AID_name ] ) должны начинаться с имени раздела, например « vendor_ », чтобы они не конфликтовали с будущими именами AOSP или другими разделами.
Определить имена OEM AID
Чтобы определить OEM AID, создайте файл config.fs и задайте значение AID. Например, в device/x/y/config.fs задайте следующее:
[AID_VENDOR_FOO] value: 2900
После создания файла установите переменную TARGET_FS_CONFIG_GEN и укажите её в BoardConfig.mk . Например, в device/x/y/BoardConfig.mk установите следующее:
TARGET_FS_CONFIG_GEN += device/x/y/config.fs
Теперь ваш пользовательский AID может использоваться всей системой в новой сборке.
Используйте OEM-средства
Чтобы использовать OEM AID, в коде на C включите oemaids_headers в соответствующий Makefile и добавьте #include "generated_oem_aid.h" , а затем начните использовать объявленные идентификаторы. Например, в my_file.c добавьте следующее:
#include "generated_oem_aid.h" … If (ipc->uid == AID_VENDOR_FOO) { // Do something ...
В соответствующем файле Android.bp добавьте следующее:
header_libs: ["oemaids_headers"],
Если вы используете файл Android.mk , то добавьте следующее:
LOCAL_HEADER_LIBRARIES := oemaids_headers
Используйте понятные имена
В Android 9 вы можете использовать понятное имя для любого интерфейса, поддерживающего имена AID. Например:
- В команде
chownвsome/init.rc:chown vendor_foo /vendor/some/vendor_foo/file
- В
serviceвsome/init.rc:service vendor_foo /vendor/bin/foo_service user vendor_foo group vendor_foo
Поскольку внутреннее сопоставление дружественного имени с uid выполняется с помощью /vendor/etc/passwd и /vendor/etc/group , раздел поставщика должен быть смонтирован.
Ассоциированные дружественные имена
В Android 9 реализована поддержка сопоставления понятного имени с фактическим значением OEM AID. Для имени пользователя и группы можно использовать нечисловые строковые аргументы, например, « vendor_foo » вместо «2901».
Преобразование из AID в понятные имена
Для OEM AID в Android 8.x требовалось использование oem_#### с getpwnam и аналогичными функциями, а также в местах, где выполняется поиск с помощью getpwnam (например, в скриптах init ). В Android 9 можно использовать функции getpwnam и getgrnam в Bionic для преобразования Android ID (AID) в понятные имена и наоборот.
Использовать возможности файловой системы
Чтобы включить возможности файловой системы, создайте раздел caps в файле config.fs . Например, в device/x/y/config.fs добавьте следующий раздел:
[system/bin/foo_service] mode: 0555 user: AID_VENDOR_FOO group: AID_SYSTEM caps: SYS_ADMIN | SYS_NICE
После создания файла настройте переменную TARGET_FS_CONFIG_GEN так, чтобы она указывала на этот файл в BoardConfig.mk . Например, в device/x/y/BoardConfig.mk укажите следующее:
TARGET_FS_CONFIG_GEN += device/x/y/config.fs
При запуске сервиса vendor_ foo он запускается с разрешениями CAP_SYS_ADMIN и CAP_SYS_NICE без вызовов setuid и setgid . Кроме того, политика SELinux сервиса vendor_ foo больше не требует разрешений setuid и setgid и может быть удалена.
Настройка переопределений (Android 6.x-7.x)
В Android 6.0 fs_config и связанные с ним определения структур ( system/core/include/private/android_filesystem_config.h ) были перемещены в system/core/libcutils/fs_config.c где их можно было обновлять или переопределять с помощью двоичных файлов, установленных в /system/etc/fs_config_dirs и /system/etc/fs_config_files . Использование отдельных правил сопоставления и анализа для каталогов и файлов (которые могли использовать дополнительные глобальные выражения) позволило Android обрабатывать каталоги и файлы в двух разных таблицах. Определения структур в system/core/libcutils/fs_config.c не только позволяли читать каталоги и файлы во время выполнения, но и хост мог использовать те же файлы во время сборки для создания образов файловой системы, таких как ${OUT}/system/etc/fs_config_dirs и ${OUT}/system/etc/fs_config_files .
Хотя метод переопределения расширения файловой системы был заменён модульной системой конфигурации, представленной в Android 8.0, при желании вы всё ещё можете использовать старый метод. В следующих разделах подробно описано, как создать и включить файлы переопределения, а также настроить файловую систему.
Генерация файлов переопределения
Выровненные двоичные файлы /system/etc/fs_config_dirs и /system/etc/fs_config_files можно сгенерировать с помощью инструмента fs_config_generate в build/tools/fs_config . Этот инструмент использует функцию библиотеки libcutils ( fs_config_generate() ) для управления требованиями DAC в буфере и определяет правила для включаемого файла для институционализации правил DAC.
Для использования создайте включаемый файл в device/ vendor / device /android_filesystem_config.h , который будет переопределять конфигурацию. Файл должен использовать формат structure fs_path_config определённый в system/core/include/private/android_filesystem_config.h со следующими инициализациями структуры для символов каталогов и файлов:
- Для каталогов используйте
android _device _dirs[]. - Для файлов используйте
android _device _files[].
Если android_device_dirs[] и android_device_files[] не используются, можно определить NO_ANDROID_FILESYSTEM_CONFIG_DEVICE_DIRS и NO_ANDROID_FILESYSTEM_CONFIG_DEVICE_FILES (см. пример ниже). Также можно указать файл переопределения с помощью TARGET_ANDROID_FILESYSTEM_CONFIG_H в конфигурации платы, при этом обязательное базовое имя будет android_filesystem_config.h .
Включить файлы переопределения
Чтобы включить файлы, убедитесь, что PRODUCT_PACKAGES включает fs_config_dirs и/или fs_config_files , чтобы их можно было установить в /system/etc/fs_config_dirs и /system/etc/fs_config_files соответственно. Система сборки ищет пользовательский файл android_filesystem_config.h в $(TARGET_DEVICE_DIR) , где находится BoardConfig.mk . Если этот файл существует в другом месте, установите переменную конфигурации платы TARGET_ANDROID_FILESYSTEM_CONFIG_H , указывающую на это расположение.
Настройте файловую систему
Чтобы настроить файловую систему в Android 6.0 и выше:
- Создайте файл
$(TARGET_DEVICE_DIR)/android_filesystem_config.h. - Добавьте
fs_config_dirsи/илиfs_config_filesвPRODUCT_PACKAGESв файле конфигурации платы (например,$(TARGET_DEVICE_DIR)/device.mk).
Пример переопределения
В этом примере показан патч для переопределения демона system/bin/glgps для добавления поддержки блокировки сна в каталоге device/ vendor / device . Имейте в виду следующее:
- Каждая запись структуры — это режим, uid, gid, возможности и имя.
system/core/include/private/android_filesystem_config.hвключается автоматически для предоставления манифеста #defines (AID_ROOT,AID_SHELL,CAP_BLOCK_SUSPEND). - Раздел
android_device_files[]включает действие, запрещающее доступ кsystem/etc/fs_config_dirs, если не указано иное, что служит дополнительной защитой DAC от отсутствия содержимого для переопределения каталогов. Однако эта защита слаба: если кто-то контролирует/system, он, как правило, может делать с ним всё, что захочет.
diff --git a/android_filesystem_config.h b/android_filesystem_config.h
new file mode 100644
index 0000000..874195f
--- /dev/null
+++ b/android_filesystem_config.h
@@ -0,0 +1,36 @@
+/*
+ * Copyright (C) 2015 The Android Open Source Project
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+ * implied. See the License for the specific language governing
+ * permissions and limitations under the License.
+ */
+
+/* This file is used to define the properties of the file system
+** images generated by build tools (eg: mkbootfs) and
+** by the device side of adb.
+*/
+
+#define NO_ANDROID_FILESYSTEM_CONFIG_DEVICE_DIRS
+/* static const struct fs_path_config android_device_dirs[] = { }; */
+
+/* Rules for files.
+** These rules are applied based on "first match", so they
+** should start with the most specific path and work their
+** way up to the root. Prefixes ending in * denotes wildcard
+** and will allow partial matches.
+*/
+static const struct fs_path_config android_device_files[] = {
+ { 00755, AID_ROOT, AID_SHELL, (1ULL << CAP_BLOCK_SUSPEND),
"system/bin/glgps" },
+#ifdef NO_ANDROID_FILESYSTEM_CONFIG_DEVICE_DIRS
+ { 00000, AID_ROOT, AID_ROOT, 0, "system/etc/fs_config_dirs" },
+#endif
+};
diff --git a/device.mk b/device.mk
index 0c71d21..235c1a7 100644
--- a/device.mk
+++ b/device.mk
@@ -18,7 +18,8 @@ PRODUCT_PACKAGES := \
libwpa_client \
hostapd \
wpa_supplicant \
- wpa_supplicant.conf
+ wpa_supplicant.conf \
+ fs_config_files
ifeq ($(TARGET_PREBUILT_KERNEL),)
ifeq ($(USE_SVELTE_KERNEL), true)
Перенос файловых систем из более ранних версий
При переносе файловых систем с Android 5.x и более ранних версий имейте в виду, что Android 6.x
- Удаляет некоторые включения, структуры и встроенные определения.
- Требуется ссылка на
libcutilsвместо непосредственного запуска изsystem/core/include/private/android_filesystem_config.h. Приватные исполняемые файлы производителя устройства, зависящие отsystem/code/include/private_filesystem_config.hдля структур файлов, каталогов илиfs_config, должны добавлять зависимости от библиотекиlibcutils. - Требуются копии частной ветки производителя устройства
system/core/include/private/android_filesystem_config.hс дополнительным содержимым на существующих целях для перемещения вdevice/ vendor / device /android_filesystem_config.h. - Оставляет за собой право применять обязательные элементы управления доступом SELinux (MAC) к файлам конфигурации в целевой системе; реализации, включающие пользовательские целевые исполняемые файлы с использованием
fs_config()должны гарантировать доступ.