Mechanical extension of mount directories to also support product/
and product_services/ as individually supplied images.
NB: In the distant past, a prototype placing the make rules into a
macro was rejected as too difficult to maintain within the macro
rules, so rules are rolled-out to make them easy to understand.
Test: compile
Bug: 119310326
Change-Id: Ief137cbe62db7175ee02275804ff1d644858dc3d
Content from fs_config designated for other partitions is leaking
into the system fs_config_* files. Notably /vendor is showing up.
Rule expansion happens late, after all parsing. This is the same in
make and kati. build/make/tools/fs_config/Android.mk ends with
fs_config_generate_extra_partition_list :=, so by the time you get to
rule expansion the value is empty.
Added a PRIVATE_PARTITION_LIST variable to record the value of
fs_config_generate_extra_partition-list.
Test: inspect result of ${OUT}/product/*/system/etc/fs_config_files
Bug: 119677224
Bug: 119310326
Change-Id: I968b4936ab2c5d174f164c760820af13434654ca
This was already done for partitions other than the system partition.
Add new, separate "_system" targets, and add new phony modules which
collects _system and _nonsystem targets for now.
Update the base_system.mk file to only depend on the system module, and
put the other ones in base_vendor.mk for now.
Bug: 80410283
Test: make fs_config_dirs[_*] fs_config_files[_*] and verify output
Change-Id: I7843578dbb9f27edf4c1e5b4a795a530f79e0be1
Previously we only created these if the device set
TARGET_FS_CONFIG_GEN, however there are now other targets that want to
depend on these. Instead of having those targets conditionally depend
on them, we always create them, defaulting to blank contents (by
reading /dev/null for TARGET_FS_CONFIG_GEN).
Test: builds succeed
Change-Id: Ie95286f5a800d891022eb66cd6fefcc967000c2e
These entries are vendor provided and belong on the /vendor partition.
Bug: 27999086
Test: end to end user/group check via config.fs and getpwnam, etc.
Change-Id: I9a5d56da594bf0d04de2b9ce7fd7d9a8151d4682
Clear fs_config_generate_extra_partition_list after use.
Test: build fs_config_files and fs_config_dirs targets.
Change-Id: Ie18bcd2df2ff1becb178e9ba45d226e2e9a8faab
Signed-off-by: William Roberts <william.c.roberts@intel.com>
Misspelled fs_config_generate_extra_partition_list when used to
calculate LOCAL_REQUIRED_MODULES dependencies. This resulted in
fs_config_dirs and fs_config_files failing to generate the vendor,
oem or odm variants (ie: fs_config_files_vendor)
Test: build generates correct fs_config override files.
Bug: 37721445
Bug: 36071012
Change-Id: I053dd5cdb357c7cea05a5ff63b0686bd0bc99df6
Add build targets to generate the vendor, oem and odm slices of the
fs_config_dirs and fs_config_files targets for each of the respective
filesystems, and automatically trigger the individual and enabled
partition build objects based as dependents of fs_config_dirs and
fs_config_files.
Sensitive to the following board definition pairs:
BOARD_VENDORIMAGE_FILE_SYSTEM_TYPE BOARD_USES_VENDORIMAGE
BOARD_OEMIMAGE_FILE_SYSTEM_TYPE BOARD_USES_OEMIMAGE
BOARD_ODMIMAGE_FILE_SYSTEM_TYPE BOARD_USES_ODMIMAGE
Which when defined and set means the images are generated for vendor,
oem or odm respectively.
Test: manually build w/ m 'fs_config_(dirs|files)_(vendor|oem|odm)'
and check the expected products, or fails if not pertinent.
Test: build for product that produces split to system and vendor and
subsequently boots with vendor products correctly configured.
Bug: 36071012
Change-Id: I44289a3dd50b7657367c826ad813c671a3de6afc
This reverts commit fad4b4b715.
Incorporating the following fixes:
1.
fsconfig: fix fs_config_* build for discovered headers
When android_file system_config.h is picked up from the device
directory, neither TARGET_FS_CONFIG_GEN or TARGET_ANDROID_FILESYSTEM_CONFIG_H
are specified. Thus, the build is not generating the required fs_config_files
and fs_config_dirs.
Test: Ensure that make fs_config_files works, and produces the same output as before
Build the system image and mount it as a loop back and dump the file system
capabilities with getcap. Verify that output to the supplied
android_file system_config.h
From the loopback of the system.img mount, from CWD system/bin:
$ getcap *
cnss-daemon = cap_net_bind_service+ep
hostapd = cap_net_admin,cap_net_raw+ep
imsdatadaemon = cap_net_bind_service+ep
ims_rtp_daemon = cap_net_bind_service+ep
logd = cap_setgid,cap_audit_control,cap_syslog+ep
mm-qcamera-daemon = cap_sys_nice+ep
pm-service = cap_net_bind_service+ep
run-as = cap_setgid,cap_setuid+ep
surfaceflinger = cap_sys_nice+ep
webview_zygote32 = cap_setgid,cap_setuid,cap_setpcap+ep
webview_zygote64 = cap_setgid,cap_setuid,cap_setpcap+ep
Compared to the android_filesystem_config.h:
{ 00700, AID_CAMERA, AID_SHELL, (1ULL << CAP_SYS_NICE), "system/bin/mm-qcamera-daemon" },
{ 00755, AID_SYSTEM, AID_SYSTEM, (1ULL << CAP_NET_BIND_SERVICE), "system/bin/pm-service" },
{ 00755, AID_SYSTEM, AID_SYSTEM, (1ULL << CAP_NET_BIND_SERVICE), "system/bin/imsdatadaemon" },
{ 00755, AID_SYSTEM, AID_RADIO, (1ULL << CAP_NET_BIND_SERVICE), "system/bin/ims_rtp_daemon" },
{ 00755, AID_SYSTEM, AID_SYSTEM, (1ULL << CAP_NET_BIND_SERVICE), "system/bin/cnss-daemon"},
2.
fsconfig: fix error message for duplicate AID
Fixes:
raise ValueError('Duplicate aid value "%u" for %s' % value,
TypeError: %u format: a number is required, not str
and
raise ValueError('Duplicate aid value "%s" for %s' % value,
TypeError: not enough arguments for format string
3.
fsconfig: add test for duplicate ranges
Add a test for duplicate range detection.
4.
fsconfig: skip AID_APP, AID_USER and all ranges
Do not output AID_APP, AID_USER and ranges. A range
is defined as ending with AID_ and ending in _START or
_END.
5.
fsconfig: test for skip AID_APP, AID_USER and all ranges
Test against AIDs that caused the bionic tests to fail.
Change-Id: I95569a9ccc83bd3231f8a6f395532cc2de316bd2
Signed-off-by: William Roberts <william.c.roberts@intel.com>
When configuring fs_config_files or fs_config_dirs for file_system
capabilities, drop the requirement that OEMs must add the target
to PRODUCT_PACKAGES. This limits the configuration requirement
to only needing to set the new and preferred TARGET_FS_CONFIG_GEN
or the older TARGET_ANDROID_FILESYSTEM_CONFIG_H method.
Test: That only setting TARGET_FS_CONFIG_GEN results in passwd and
group in the build image.
Change-Id: I818854fa1b3e94edaff59a32bd7cf23cf9b504aa
Signed-off-by: William Roberts <william.c.roberts@intel.com>
Introduce a generator that outputs group files per man(5) group.
Succinctly, the output is a colon delimited string containing the following
fields:
* group name
* encrypted password (optional)
* gid (int)
* userlist (str,...)
Multiple colon delimited lines may exist, but will not be separated
across lines.
Sample generator output:
foo::2900:
foo_bar::2901:
custom_oem1::2902:
Test: That make group produces the group file.
Change-Id: Idd3fe925a09a227c6e894e1b5d2b3873b01531c6
Signed-off-by: William Roberts <william.c.roberts@intel.com>
Introduce a generator that outputs passwd files per man(5) passwd.
Succinctly, the output is a colon delimited string containing the following
fields:
* login name
* encrypted password (optional)
* uid (int)
* gid (int)
* User name or comment field
* home directory
* interpreter (optional)
Multiple colon delimited lines may exist, but will not be separated
across lines.
When run, produces:
foo::2900:2900::/:/system/bin/sh
foo_bar::2901:2901::/:/system/bin/sh
custom_oem1::2902:2902::/:/system/bin/sh
Note that this generator allows for 0 or more config.fs files. This allows for:
* Unconditional inclusion of /system/etc/passwd in the generated image
* A blank passwd file if no config.fs files are specified.
This ensures that when OEMs add config.fs files, there is no additional steps
for proper functionality (simpler for OEMs).
The one draw back is the additional inode consumption on system for a possible
blank file.
Test: That it produces a valid passwd file.
Change-Id: I19691c8260f02147ed861f8a319aeab3f5b1738e
Signed-off-by: William Roberts <william.c.roberts@intel.com>
Generate an OEM AID_<name> header file seperate from fs_config
header file and provide details on how to export this interface
into native code.
Test: That ls, ps, chown and services function for built in
services as before.
Change-Id: Ie8ce6585e0721b52633ee50d62dcfe796e178f65
Signed-off-by: William Roberts <william.c.roberts@intel.com>
Rather than hardcode the OEM ranges, parse and extract
AID values from android_filesystem_config.h.
An AID is defined to the tool as:
* #define AID_<name>
An OEM Range is defined to the the tool as:
* AID_OEM_RESERVED_START
* AID_OEM_RESERVED_END
or
* AID_OEM_RESERVED_N_START
* AID_OEM_RESERVED_N_END
Where N is a number.
While parsing, perform sanity checks such as:
1. AIDs defined in the header cannot be within OEM range
2. OEM Ranges must be valid:
* Cannot overlap one another.
* Range START must be less than range END
3. Like the C preproccessor, multiple matching AID_<name> throws
en error.
The parser introduced here, prepares the tool to output android_ids
consumable for bionic.
Note that some AID_* friendly names were not consistent, thus a small
fixup map had to be placed inside the tool.
Test: tested parsing and dumping the data from android_filesystem_config.h
file.
Change-Id: Ifa4d1c9565d061b60542296fe33c8eba31649e62
Signed-off-by: William Roberts <william.c.roberts@intel.com>
This internally structures fs_config_generator.py to be able
to plug in generators to produce different outputs. This
prepares this tool for group and pwd file outputs.
Test: Checked diff and hash of before and after files.
Change-Id: Ie558518ac227dd946d70ab48027698b72a9bc94a
Signed-off-by: William Roberts <william.c.roberts@intel.com>
Introduce TARGET_FS_CONFIG_GEN, an option for generating
android_filesystem_config.h files from multiple intermediate
file formats. See the README for more details.
Change-Id: Ibdb2f65702657802e34b0cec18fb43709d7452bb
Signed-off-by: William Roberts <william.c.roberts@intel.com>
Multiple files added to TARGET_ANDROID_FILESYSTEM_CONFIG_H will build,
however the tooling will only respect the first header found. The
sanity check in the makefile will only check the first path found for
proper naming convention. One can end up with a successful build that
does not respect all files in the TARGET_ANDROID_FILESYSTEM_CONFIG_H.
Check that one and only one item is set to
TARGET_ANDROID_FILESYSTEM_CONFIG_H variable.
Output:
*** Multiple fs_config files specified, see "device/lge/bullhead/two/android_filesystem_config.h device/lge/bullhead/one/android_filesystem_config.h"..
Change-Id: I70a43f44713b273cb9a78f54ff16854b9e11af4a
Signed-off-by: William Roberts <william.c.roberts@intel.com>
fs_config_generate_$(TARGET_DEVICE) is built based off the content
of $(TARGET_ANDROID_FILESYSTEM_CONFIG_H). We also add the rules
fs_config_dirs and fs_config_file to utilize this command
for target contents:
fs_config_generate_$(TARGET_DEVICE) -D -o system/etc/fs_config_dir
fs_config_generate_$(TARGET_DEVICE) -F -o system/etc/fs_config_file
In order to use this feature, one must have the fs_config_dirs and
fs_config_files in the $(PRODUCT_PACKAGES) list defined in the
device make files in $(TARGET_DEVICE_DIR). And either an
android_filesystem_config.h file in that directory, or define a
path in TARGET_ANDROID_FILESYSTEM_CONFIG_H to point to one.
Bug: 19908228
Change-Id: Iee1543d99169f874e0915ae07962a7750ecb6342
- move to libcutils.so and libselinux.so as shared now that
they are in DISTTOOL.
- liblog dependency is part of libcutils, and need not be
called out explicitly now. liblog is in DISTTOOL.
- libcutils fs_config has the right to add Android logging
Bug: 19908228
Change-Id: Iaa60ad624b42d83653840ac3c77bfa03ad8674aa
Update the OTA generation script to understand SELinux file
labels and file capabilities.
Make fs_config aware of SELinux labels and file capabilities, and
optionally output those elements whenever we output the
UID / GID / file perms. The information is emitted as a key=value pair
to allow for future extensibility.
Pass the SELinux file label and capabilities to the newly created
set_metadata() and set_metadata_recursive() calls. When the OTA
script fixes up filesystem permissions, it will also fix up the SELinux
labels and file capabilities.
If no SELinux label and capabilities are available for the file, use
the old set_perm and set_perm_recursive calls.
Bug: 8985290
Bug: 10183961
Bug: 10186213
Change-Id: I4fcfb2c234dbfb965cee9e62f060092a4274d22d
Make fs_config aware of SELinux contexts, and output the context
whenever we output the UID / GID / file perms.
Pass the selinux context to the set_perm2() and set_perm2_recursive()
calls. When the OTA script fixes up filesystem permissions, it will
also fix up the SELinux context on the files.
Bug: 8985290
Change-Id: I6419b64c06309a93ac6b2f2cf9fc7f8815adeaf3
Mark Salyzyn