Lines Matching refs:and

2 title: Users, Groups, UIDs and GIDs on systemd Systems
3 category: Users, Groups and Home Directories
8 # Users, Groups, UIDs and GIDs on systemd Systems
10 Here's a summary of the requirements `systemd` (and Linux) make on UID/GID
11 assignments and their ranges.
13 Note that while in theory UIDs and GIDs are orthogonal concepts they really
15 that whatever we say about UIDs applies to GIDs in mostly the same way, and all
16 the special assignments and ranges for UIDs always have mostly the same
31    bit confused the `nobody` user is called `nfsnobody` there (and they have a
37    `setresuid()`, `chown()` and friends treat -1 as a special request to not
42    16bit, and programs compiled for that would hence assume that `(uid_t) -1`
46 the UIDs 0 and 65534 if the system user database doesn't list them. This means
56    privilege separation and run system daemons with minimal privileges.
58 2. 1000…65533 and 65536…4294967294 → Everything else, i.e. regular (human) users.
60 Note that most distributions allow changing the boundary between system and
72 Note that systemd requires that system users and groups are resolvable without
103    and persisted locally on first login. On different systems the same user
117    if you write them in hexadecimal, they might make more sense: 0xEF00 and
126    range and assign it to the container. The range is picked so that the upper
135    erroneously considers UIDs signed integers, and hence can't deal with values
141 checked for collisions first, and a different UID is picked if an entry is
143 exclusive ownership of UIDs and UID ranges. To ensure compatibility with other
146 providing an NSS module, or by adding entries directly to `/etc/passwd` and
177 compiled with `-Dcompat-mutable-uid-boundaries=true` and that file is present.
178 Support for this is considered only a compatibility feature and should not be
183 If you hack on a container manager, and wonder how and how many UIDs best to
187 user has magic properties, and hence should be available in your container, and
190 user records for the `nobody` user, and assumes its availability in various
200 65536 UIDs per container, and neither less nor more. A pretty side-effect is
209 `systemd-nspawn` and all other container managers following the scheme, as it
215 just mask away the upper 16bit, and insert the upper 16bit of the new container
217 external UID, and the container base UID from each other:
230 in the user database, and make sure that the NSS module returns up-to-date
237 mapping applied. It will map four UID ranges into that uidmap, and leave
239 60514…65534, and the container range 524288…1879048191. This means
244 these ranges into consideration and either place the trees at base UID 0 (and
247 UID range. That said, placing container trees (and in fact any
252 permission problems, introduces security issues around SETUID and severely
281 pre-defined purposes between Linux, generic low-level distributions and
293 ## Notes on resolvability of user and group names
295 User names, UIDs, group names and GIDs don't have to be resolvable using NSS
296 (i.e. getpwuid() and getpwnam() and friends) all the time. However, systemd
304 `systemd-udevd.service` and `systemd-tmpfiles.service` are started, as both
312 providers of the user database and consumers of it. Services that require that
319 that really needs it, and that means only if there's a service providing the
322 service `Before=nss-user-lookup.target` and that you pull it in with