add tests for upper limits
This commit is contained in:
34
README.md
34
README.md
@@ -130,9 +130,10 @@ Now that we've sketched the implementation of `id(3)`, it's clearer to
|
||||
understand which operations need to be fast; in order of importance:
|
||||
|
||||
1. lookup gid -> group info (this is on hot path in id) without members.
|
||||
2. lookup uid -> user.
|
||||
3. lookup groupname -> group.
|
||||
4. lookup username -> user.
|
||||
2. lookup username -> user's group memberships.
|
||||
3. lookup uid -> user.
|
||||
4. lookup groupname -> group.
|
||||
5. lookup username -> user.
|
||||
|
||||
These indices can use perfect hashing like [bdz from cmph][cmph]: a perfect
|
||||
hash hashes a list of bytes to a sequential list of integers. Perfect hashing
|
||||
@@ -292,8 +293,25 @@ Varint is an efficiently encoded integer (packed for small values). Same as
|
||||
[protocol buffer varints][varint], except the largest possible value is `u64`.
|
||||
They compress integers well.
|
||||
|
||||
`groupmembers`, `additional_gids`
|
||||
---------------------------------
|
||||
Group memberships
|
||||
-----------------
|
||||
|
||||
There are two group memberships at play:
|
||||
|
||||
1. given a username, resolve user's group gids (for `initgroups(3)`).
|
||||
2. given a group (gid/name), resolve the members' names (e.g. `getgrgid`).
|
||||
|
||||
When user's groups are resolved in (1), the additional userdata is not
|
||||
requested (there is no way to return it). Therefore, it is reasonable to store
|
||||
the user's memberships completely out-of-bound, keyed by the hash of the
|
||||
username.
|
||||
|
||||
When group's memberships are resolved in (2), the same call also requires other
|
||||
group information: gid and group name. Therefore it makes sense to store a
|
||||
pointer to the group members in the group information itself. However, the
|
||||
memberships are not *always* necessary (see remarks about `id(1)` in this
|
||||
document), therefore the memberships will be stored separately, outside of the
|
||||
groups section.
|
||||
|
||||
`groupmembers` and `additional_gids` store group and user memberships
|
||||
respectively: for each group, a list of pointers (offsets) to User records, and
|
||||
@@ -307,16 +325,12 @@ pseudo-code:
|
||||
```
|
||||
const PackedList = struct {
|
||||
length: varint,
|
||||
members: []varint
|
||||
members: [length]varint
|
||||
}
|
||||
const Groupmembers = PackedList;
|
||||
const AdditionalGids = PackedList;
|
||||
```
|
||||
|
||||
An entry in `members` field points to the offset into a respective `User` or
|
||||
`Group` entry (number of bytes relative to the first entry of the type).
|
||||
`members` in `PackedList` are sorted the same way as in the input.
|
||||
|
||||
A packed list is a list of varints.
|
||||
|
||||
Complete file structure
|
||||
|
||||
Reference in New Issue
Block a user