The 2024Q builds don't have their own branches like QPR builds used to,
and there's no API bump until V proper, so the same CTS build needs to
cope with both last year's Android release _and_ the one that doesn't
have an API level yet. So poke holes in the uid test to support these
mismatches.
This runs the risk of allowing accidental misuse in U of the very uids
that will definitely be used in V, so check that _if_ the uids do exist,
they have the names we're expecting them to have. That should make
accidents easier to spot?
Bug: http://b/322256445
Test: treehugger
Change-Id: I3b24b8fafe20012df70c73589b40dba5a10e50e9
initgroups() is just a call to getgrouplist() followed by a call to
setgroups(). The tricky part is memory allocation. OpenBSD allocates an
NGROUPS_MAX-sized array of gid_t on the stack. FreeBSD allocates a
sysconf(_SC_NGROUPS_MAX)-sized array of gid_t on the heap. bionic had a
mix where it would try a 2-element stack array but fall back to a heap
allocation, which sounds reasonable if you want to avoid a 256KiB
(64Ki*4 bytes) allocation on either stack or heap. But that constant 2?
That's weird in two ways... It's really small (musl has an NGROUPS_MAX
of 32 unlike the Linux kernel's 64Ki, but 32 is still a lot larger than
2), but at the same time it's too big --- bionic's getgrouplist() always
returns a single element.
So although the FreeBSD "what the hell, let's just allocate 256KiB on
the heap" implementation would have been fine, there's really no point,
and anyone who's trying to understand initgroups() on Android really
needs to read getgroupslist() anyway, so let's just have the most
trivial implementation -- a single-element array -- and let's have it
right next to getgroupslist() in the same file as all the other <grp.h>
functions.
Also add a trivial smoke test. You mostly won't have permission to do
anything interesting with initgroups(), and it's basically unused save
for privilege dropping tcpdump and strace, but we may as well make an
effort. (I tested tcpdump before and after too.)
Test: treehugger
Change-Id: I67fe02e309ed1dbefc490c01733738363ca606be
We've talked about this many times in the past, but partners struggle to
understand "expected 38, got 22" in these contexts, and I always have to
go and check the header files just to be sure I'm sure.
I actually think the glibc geterrorname_np() function (which would
return "ENOSYS" rather than "Function not implemented") would be more
helpful, but I'll have to go and implement that first, and then come
back.
Being forced to go through all our errno assertions did also make me
want to use a more consistent style for our ENOSYS assertions in
particular --- there's a particularly readable idiom, and I'll also come
back and move more of those checks to the most readable idiom.
I've added a few missing `errno = 0`s before tests, and removed a few
stray `errno = 0`s from tests that don't actually make assertions about
errno, since I had to look at every single reference to errno anyway.
Test: treehugger
Change-Id: Iba7c56f2adc30288c3e00ade106635e515e88179
The PRNG seeder daemon is introduced in TM-QPR2 which can lead to
breakage running Android 13 CTS tests depending on when the platform
and CTS tests are built.
Fix: 253185870
Test: run cts --module CtsBionicTestCases
Change-Id: I94fa0aa2f32b09222aee08891e7643bf14d1a204
Mostly from extra test cases, but also:
* Move the fgets size < 0 assertion into fgets.
* Use ELF aliases for strtoq/strtouq rather than duplicating code.
* Don't check uname() succeeded, since it can't fail.
Test: treehugger
Change-Id: I2e6b3b88b0a3eb16bd68be68b9bc9f40d8043291
R GSI on P product tests fail since pw_shell has changed. This value
has no practical use on Android, so we ignore testing it for older
vendor images.
Bug: 160937247
Test: this test does/doesn't run appropriately
Change-Id: Ie485bd019b3826e71ad19131effcbb002f888d52
Previously, these tests would fail if vendors modified
private/android_filesystem_config.h to add their custom AIDs, but we
did not have a good alternative that vendors could use, so we added a
special case to ignore the vendor AID ranges.
We've had a proper solution since P for this range, so it's long past
time to remove this special case.
Test: add system, vendor, odm, product, and system_ext AIDs to
config.fs, ensure that they've taken effect on cuttlefish,
pass these unit tests
Change-Id: I6c9c2bf5e895c25805222da018188b269777171c
1) "fix the system properties design" is written for the old protocol,
so we've already changed the design. There are no other further
planned changes.
2) "don't drag in all the macros, just the types." is not likely to
happen or be particularly impactful.
3) "Find a location suitable for these functions ..." is refering to
legacy code. More likely that this code will be removed before we
find a serious reason to fix this TODO.
4) "(73062966) We still don't have a good way ..." is stale; we fixed
this bug and added the appropriate mechanism.
Test: n/a
Change-Id: I23991692cdeb81ad00844a6a1680900ff384208b
Historically we've made a few mistakes where they haven't matched the
right number. And most non-Googlers are much more familiar with the
numbers, so it seems to make sense to rely more on them. Especially in
header files, which we actually expect real people to have to read from
time to time.
Test: treehugger
Change-Id: I0d4a97454ee108de1d32f21df285315c5488d886
Note that unlike the oem_ range that is used for the vendor
partitions, we do not create oem_<n> entries for these new reserved
ranges; they will only appear in getpwent()/getgrent() if there is an
entry in the corresponding passwd/group file.
Bug: 73062966
Test: can load AIDs from partitions other than vendor
Test: bionic-unit-tests
Change-Id: Ifcbbf202894adff948eaaba2a59e25c993611140
In an attempt to make bionic's reporting of users and groups more
accurate, this change makes the user / group functions do the
following:
1) Fail to query a uid/gid for a secondary user when the uid/gid
doesn't exist. Currently bionic would return successfully but with
a empty string for the name.
2) Fail to query a platform uid/gid, except a limited pre-allocated
set for a secondary user, as these are not used by second users.
3) Fail to query uids for all users for the GID-only app ranges:
CACHE_GID, EXT_GID, EXT_CACHE_GID, SHARED_GID.
4) Fail to query gids in SHARED_GID range for secondary users, as
these GIDs are only allocated for the first user.
5) Use "u#_a#_ext" and u#_a#_ext_cache" for EXT_GID and EXT_CACHE_GID
ranges. This both allows querying based on these names and
returning these names for the appropriate uids/gids.
This also consolidates the tests for better readability.
Test: these unit tests, boot
Change-Id: I59a1af0792e7806d423439582e56ce7f9f801c94
getpwnam_r() and getpwuid_r() clobber the storage used by getpwnam()
and getpwuid(). This isn't likely to be a big issue, but since we do
this right for the group functions, fix this as well as add a test.
Both use more space in buf than is actually required, but well below
their sysconf() suggested values, so we accept that to keep the code
concise.
Add tests for dealing with unaligned input buffers, particularly for
getgrnam_r() and getgrgid_r(), as they require alignment but this
wasn't being tested.
Refactor common initialization code for both passwd and group state
structs.
Remove extraneous null pointer checks; the values they were testing
were offsets of a previous pointer, so guaranteed to never actually be
null. If the underlying pointer is actually null, we're beyond repair
anyway, so accept that we'll crash.
Test: pwd/grp unit tests
Change-Id: I60c4d00e9ab3cf55daf8314c5029fd914025b696
We still don't have a good way to create vendor AIDs in the system or
other non-vendor partitions, therefore we keep this check disabled.
Bug: 73062966
Test: treehugger
Change-Id: I7aed425899d6ec11a22702ccec82476eacdbc790
The UID range [90000..98999] is used for isolated processes that are
spawned from an application zygote. Otherwise they are identical to
regular isolated processes in the [99000..99999] range. Fix the tests to
match the new range.
Bug: 111434506
Test: atest bionic-unit-tests-static
Change-Id: Id0352f2cf0d21edb04d95f01ea2548e95b62317a
Some vendors may have been using the AIDs outside the oem ranges
for long that those aids need continue to be maitained for the
existing devices. We allow them countinue to use the old AID names
and values on device launch with P and before, to give them the
period of time to adopt the new AID scheme.
Bug: 116405200
Change-Id: I0453ed14df4c0855575ef1404c596ddc6ded681b
We added a check in P that ensures all vendor provided AIDs only
appear in the carved out ranges for vendors to use. However,
upgrading devices may be using AIDs outside of this range and it is
very difficult to change these AIDs, so we waive this test for them.
Bug: 116830906
Test: test succeeds on upgrading devices
Change-Id: Iddcacb1dce77a150d5138e7b3115abf25bf60a6e
During the review of the script that generates /vendor/etc/passwd, it
was suggested that the shell be /vendor/bin/sh instead of the typical
/system/bin/sh. This has subsequently caused bionic unit tests to
fail, since they always check that the shell is set to /system/bin/sh.
In the spirit of that review, libc is modified to return
/vendor/bin/sh for the OEM AID ranges and the test is updated to
expect this.
Test: bionic unit tests
Change-Id: Ie7c1c48fde8a71b3df1aa0ef112d42ab7bd3baec
Now that we're only processing vendor AID names that begin with
vendor_, add an explicit test to fail devices that use AID names
without this prefix.
Bug: 79528966
Test: Pass if no vendor defined AIDs are present
Test: Pass if vendor defined AIDs are present with vendor_ prefix
Test: Fail if vendor defined AIDs are present without vendor_ prefix
Change-Id: I77c559800b4904f58c49fbe339e4daad7d953089
Vendors that use config.fs will have their own uniquely named
user/group names for uids/gids that fall in the OEM ranges. We
continue to allow lookup via oem_## for these values, however the
returned structs will always include the name from config.fs, so we do
not check it for anything in the tests.
Bug: 77549259
Test: bionic unit tests with uid 5000 as AID_CRAS
Change-Id: I27fc1fdd0e22063fea82b4c9d2a6fb8b865c5d7b
These tests aren't meaningful on the host, and take forever to fail.
Test: bionic-unit-tests-glibc --gtest_filter="*get??ent_iterate"
Change-Id: I8ca20829ba94f2ea815c636f779bacc55449cffd
We now have a proper mechanism for OEMs to create new AIDs via
config.fs and /vendor/etc/{passwd,group}. This means that there is no
reason for OEMs to add AIDs by modifying android_filesystem_config.h,
and therefore we can add this check back.
Bug: 27999086
Test: pwd and grp tests pass with custom AIDs in config.fs
This reverts commit a14485adde.
Change-Id: I74a28ff267a595e83cf692b27fd8b5170a021f54
Currently, getpwnam, getpwent, etc return successfully for any uid
from AID_APP_START (10000) to AID_USER_OFFSET (100000) for each user.
This is not correct however, as only specific ranges above
AID_APP_START are reserved as valid ranges. This change corrects this.
This is particularly important as the newly added AID_OVERFLOWUID is
65534, which is above AID_APP_START but not in any reserved range,
collided with the faulty returned values.
Bug: 69119022
Bug: 69128408
Test: pwd/grp bionic unit tests
Change-Id: I3dae97a90597915fa30a88fe27cda88b107e9c35
grp_pwd_test.cpp uses ASSERT_ where EXPECT_ is possible, causing
missing failures when multiple failures are present.
Also, print out the uid/gid in the _iterate tests, to make debugging
easier.
Test: these same unit tests
Change-Id: I839b74fb86232b3e896091e76ab862cc5b6b8782
Remove the check that AIDs in the OEM range are not defind in
android_filesystem_config, as we do not yet have a good solution for
OEMs to define custom AIDs and what OEMs are currently doing isn't
hurting anything.
Bug: b/64137613
Test: pwd.getpwent_iterate / grp.getgrent_iterate
Change-Id: If98ad4443fe9e827e3f17b3df92eca82763e6290
To support upcoming disk usage calculation optimizations, this change
creates a new GID for each app that will be used to mark its cached
data. We're allocating these unique GIDs so that we can use
quotactl() to track cached data on a per-app basis.
Test: builds, boots, tests pass
Bug: 27948817
Change-Id: Ic00c39ccedc23d5d43988029e9921679126f8f2d
Generate the android_ids array and include into the
build.
Test: The bionic is built and that core AIDs work as
expected with commands like chown, mkdir and init services
and builtins.
Bug: 27999086
Change-Id: Ib575bf85326c91801c5674db475dcb9cf44c00dc
Signed-off-by: William Roberts <william.c.roberts@intel.com>
Not efficient to iterate through given the large number of Android
ids (AID). Compile warning will result if you use these functions,
telling you as much. Not for general consumption, however for
example, some filesystem tests would like to see these to perform
all corners.
About 1/4 second for getpwent, and 1/8 second for getgrent to iterate
through all reserved Android aids.
Bug: 27999086
Change-Id: I7784273b7875c38e4954ae21d314f35e4bf8c2fc
The XXXX now lines up to the underlying uid and has no offset.
Work with AID_OEM_RESERVED uids.
Test uses hard coded values to catch changes in the API expectations
that may occur in private/android_filesystem_config.h.
SideEffects: names change, some product dependencies.
Bug: 27999086
Change-Id: Ic2b4c36de74ae009a44e14711c75834293828207
