Lines Matching refs:user

24 1. 0 → The `root` super-user
28    only supporting 16bit UIDs, NFS or user namespacing. (The latter can be
31    bit confused the `nobody` user is called `nfsnobody` there (and they have a
32    different `nobody` user at UID 99). I hope this will be corrected eventually
36 3. 4294967295, aka "32bit `(uid_t) -1`" → This UID is not a valid user ID, as
39    assignment to users in the user database.
45 The `nss-systemd` glibc NSS module will synthesize user database records for
46 the UIDs 0 and 65534 if the system user database doesn't list them. This means
61 regular users, even during runtime as user configuration. Moreover, some older
69 available regular user range only, usually 1000..60000. And it's also usually
70 user-configurable, too.
103    and persisted locally on first login. On different systems the same user
106    the user name.
113    assign a 64K range of UIDs to containers using user namespacing. This range
118    0xFFEF). The `nss-systemd` module will synthesize user records implicitly
120    user record resolving works correctly without those users being in
136    above 2^31. The `systemd-machined.service` service will synthesize user
142 found. Thus, the user database is used as synchronization mechanism to ensure
145 ensure that whatever they pick shows up in the user/group databases, either by
150 `lckpwdf()` user database lock is taken, in order to make this logic race-free.
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
198 dynamic user concept allocate from above the 16bit range). Unless you actively
226 a simple `getpwuid()` call: if there's already a user record for the first UID
230 in the user database, and make sure that the NSS module returns up-to-date
232 safely use the NSS user database as allocation check, too. Note that if you
238 everything else unmapped: the range from 0…60000, the user's own UID, the range
245 then map them to a higher UID range for use in user namespacing via another
248 files/directories not owned by the home directory's user) in home directories
261 |                     0 | `root` user           | Linux         | `/etc/passwd` + `nss-systemd` |
271 |                 65534 | `nobody` user         | Linux         | `/etc/passwd` + `nss-systemd` |
293 ## Notes on resolvability of user and group names
310 be resolvable at the point in time the `nss-user-lookup.target` unit is
312 providers of the user database and consumers of it. Services that require that
313 the user database is fully available (for example, the login service
315 parts of the user database (for example an LDAP user database client) are
316 ordered *before* it. Note that `nss-user-lookup.target` is a *passive* unit: in
320 local user database somehow through IPC or suchlike. Or in other words: if you
321 hack on some networked user database project, then make sure you order your
322 service `Before=nss-user-lookup.target` and that you pull it in with
323 `Wants=nss-user-lookup.target`. However, if you hack on some project that needs
324 the user database to be up in full, then order your service
325 `After=nss-user-lookup.target`, but do *not* pull it in via a `Wants=`