pax_global_header00006660000000000000000000000064143147105760014522gustar00rootroot0000000000000052 comment=a12528f055292b0634de829bc51608a9e1679d2a cromerc-opensysusers-a12528f/000077500000000000000000000000001431471057600162665ustar00rootroot00000000000000cromerc-opensysusers-a12528f/.gitignore000066400000000000000000000001421431471057600202530ustar00rootroot00000000000000/man/*.1 /man/*.5 /man/*.8 /man/*.html /bin/sysusers /bin/opensysusers /openrc/opensysusers.initd cromerc-opensysusers-a12528f/LICENSE000066400000000000000000000024771431471057600173050ustar00rootroot00000000000000Copyright (c) 2017 - 2018, Chris Cromer Copyright (c) 2012, Gentoo Foundation All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. cromerc-opensysusers-a12528f/Makefile000066400000000000000000000057631431471057600177410ustar00rootroot00000000000000SYSCONFDIR = /etc PREFIX ?= /usr/local BINDIR = $(PREFIX)/bin LIBDIR = $(PREFIX)/lib MANDIR = $(PREFIX)/share/man DOCDIR = $(PREFIX)/share/doc/opensysusers TESTDIR = /run/sysusers.d BINMODE = 0755 MODE = 0644 INSTALL = install MAKE = make HAVESYSTEMD = yes HAVEOPENRC = no HAVEMAN = yes HAVEDOC = no INITD = opensysusers.initd BASIC = basic.conf ifeq ($(HAVESYSTEMD),yes) BINNAME = sysusers else BINNAME = opensysusers endif TESTFILES = $(wildcard test/*.conf) all: sysusers ifeq ($(HAVEOPENRC),yes) all: $(INITD) endif ifeq ($(HAVEMAN),yes) all: +$(MAKE) HAVEDOC=$(HAVEDOC) INSTALL=$(INSTALL) DOCMODE=$(MODE) MANDIR=$(MANDIR) DOCDIR=$(DOCDIR) DESTDIR=$(DESTDIR) -C man endif EDIT = sed "s|@BINNAME[@]|$(BINNAME)|" RM = rm -f CHMOD = chmod $(BINMODE) opensysusers: sysusers $(INSTALL) $< $@ $(INITD): $(INITD).in @echo "GEN $@" @$(RM) "$@" @$(EDIT) $< >"$@" @$(CHMOD) "$@" clean-openrc: $(RM) $(INITD) clean-man: +$(MAKE) INSTALL=$(INSTALL) DOCMODE=$(MODE) MANDIR=$(MANDIR) DOCDIR=$(DOCDIR) DESTDIR=$(DESTDIR) -C man clean clean: clean-bin ifeq ($(HAVEOPENRC),yes) clean: clean-openrc endif ifeq ($(HAVEMAN),yes) clean: clean-man endif install-shared: $(INSTALL) -Dm $(MODE) $(BASIC) $(DESTDIR)$(LIBDIR)/sysusers.d/$(BASIC) install-default-bin: sysusers $(INSTALL) -Dm $(BINMODE) sysusers $(DESTDIR)$(BINDIR)/$(BINNAME) install-custom-bin: sysusers $(INSTALL) -Dm $(BINMODE) sysusers $(DESTDIR)$(BINDIR)/$(BINNAME) install-openrc: $(INITD) $(INSTALL) -Dm $(BINMODE) $(INITD) $(DESTDIR)$(SYSCONFDIR)/init.d/opensysusers install-man: +$(MAKE) INSTALL=$(INSTALL) DOCMODE=$(MODE) MANDIR=$(MANDIR) DOCDIR=$(DOCDIR) DESTDIR=$(DESTDIR) -C man install install-tests: $(INSTALL) -Dm $(MODE) $(TESTFILES) $(DESTDIR)$(TESTDIR)/ uninstall-shared: $(RM) $(DESTDIR)$(LIBDIR)/sysusers.d/$(BASIC) uninstall-default-bin: $(RM) $(DESTDIR)$(BINDIR)/$(BINNAME) uninstall-custom-bin: $(RM) $(DESTDIR)$(BINDIR)/$(BINNAME) uninstall-openrc: $(RM) $(DESTDIR)$(SYSCONFDIR)/init.d/opensysusers uninstall-man: +$(MAKE) INSTALL=$(INSTALL) DOCMODE=$(MODE) MANDIR=$(MANDIR) DOCDIR=$(DOCDIR) DESTDIR=$(DESTDIR) -C man uninstall ifeq ($(HAVESYSTEMD),yes) install: install-shared uninstall: uninstall-shared ifeq ($(HAVEMAN),yes) install: install-man uninstall: uninstall-man endif ifeq ($(BINNAME),sysusers) install: install-default-bin uninstall: uninstall-default-bin else install: install-custom-bin uninstall: uninstall-custom-bin endif ifeq ($(HAVEOPENRC),yes) install: install-openrc uninstall: uninstall-openrc endif else install: install-shared install-default-bin uninstall: uninstall-shared uninstall-default-bin ifeq ($(HAVEMAN),yes) install: install-man uninstall: uninstall-man endif ifeq ($(HAVEOPENRC),yes) install: install-openrc uninstall: uninstall-openrc endif endif .PHONY: all install install-custom-bin install-default-bin install-man install-openrc install-shared install-tests uninstall uninstall-custom-bin uninstall-default-bin uninstall-man uninstall-openrc uninstall-shared clean clean-bin clean-man clean-openrc cromerc-opensysusers-a12528f/README.md000066400000000000000000000012141431471057600175430ustar00rootroot00000000000000This is a utility written to process sysusers.d files so that they can be handled on systems with or without systemd installed. For more information on the files this utility can process, see the sysusers.d man page [1]. For more information on the systemd-sysuser command, see the systemd-sysuers man page [2]. If built with the make flag SYSTEMDCOMPAT=FALSE, it will only install the basic script to process sysusers.d conf files. Otherwise it installs a script that imitates systemd-sysusers command. [1] https://www.freedesktop.org/software/systemd/man/sysusers.d.html [2] https://www.freedesktop.org/software/systemd/man/systemd-sysusers.htmlcromerc-opensysusers-a12528f/basic.conf000066400000000000000000000021601431471057600202150ustar00rootroot00000000000000# This file is part of systemd. # # systemd is free software; you can redistribute it and/or modify it # under the terms of the GNU Lesser General Public License as published by # the Free Software Foundation; either version 2.1 of the License, or # (at your option) any later version. # The superuser u root 0 "Super User" /root # The nobody user for NFS file systems u nobody 65534 "Nobody" - # Administrator group: can *see* more than normal users g adm - - - # Administrator group: can *do* more than normal users g wheel - - - # Access to certain kernel and userspace facilities g kmem - - - g tty 5 - - g utmp - - - # Hardware access groups g audio - - - g disk - - - g input - - - g kvm - - - g lp - - - g optical - - - g render - - - g storage - - - g uucp - - - g video - - - # Default group for normal users g users - - - cromerc-opensysusers-a12528f/man/000077500000000000000000000000001431471057600170415ustar00rootroot00000000000000cromerc-opensysusers-a12528f/man/Makefile000066400000000000000000000050241431471057600205020ustar00rootroot00000000000000manfiles5 = sysusers.d.5 manfiles8 = systemd-sysusers.8 systemd-sysusers.service.8 docfiles = UIDS-GIDS.html USER_NAMES.html xsltargs = --nonet \ --xinclude \ --maxdepth 9000 \ --stringparam man.output.quietly 1 \ --stringparam funcsysnopsis.style ansi \ --stringparam man.authors.section.enabled 0 \ --stringparam man.copyright.section.enabled 0 \ --stringparam systemd.version 238.51 all: man ifeq ($(HAVEDOC),yes) all: doc endif man: xsltproc $(xsltargs) custom-man.xsl systemd-sysusers.xml xsltproc $(xsltargs) custom-man.xsl sysusers.d.xml doc: if command -v cmark-gfm; then \ md='cmark-gfm --extension table'; \ elif command -v cmark; then \ md='cmark'; \ else \ md='markdown'; \ fi; \ $$md UIDS-GIDS.md > UIDS-GIDS.html; \ $$md USER_NAMES.md > USER_NAMES.html # Delete files because wget can't overwrite them download-docs: rm -f *.xml *.xsl if command -v wget; then \ download='wget'; \ elif command -v curl; then \ download='curl --location --remote-name-all'; \ elif command -v fetch; then \ download='fetch'; \ fi; \ $$download \ 'https://github.com/systemd/systemd/raw/main/man/custom-html.xsl' \ 'https://github.com/systemd/systemd/raw/main/man/custom-man.xsl' \ 'https://github.com/systemd/systemd/raw/main/man/standard-options.xml' \ 'https://github.com/systemd/systemd/raw/main/man/standard-specifiers.xml' \ 'https://github.com/systemd/systemd/raw/main/man/systemd-sysusers.xml' \ 'https://github.com/systemd/systemd/raw/main/man/sysusers.d.xml' \ 'https://github.com/systemd/systemd/raw/main/docs/UIDS-GIDS.md' \ 'https://github.com/systemd/systemd/raw/main/docs/USER_NAMES.md' clean: rm -f $(manfiles5) rm -f $(manfiles8) rm -f $(docfiles) install-man: $(INSTALL) -d $(DESTDIR)$(MANDIR)/man5 $(DESTDIR)$(MANDIR)/man8 $(INSTALL) -m $(DOCMODE) $(manfiles5) $(DESTDIR)$(MANDIR)/man5 $(INSTALL) -m $(DOCMODE) $(manfiles8) $(DESTDIR)$(MANDIR)/man8 install-doc: $(INSTALL) -d $(DESTDIR)$(DOCDIR) $(INSTALL) -m $(DOCMODE) $(docfiles) $(DESTDIR)$(DOCDIR) install: install-man ifeq ($(HAVEDOC),yes) install: install-doc endif uninstall-man: for man in ${manfiles5}; do rm -f $(DESTDIR)$(MANDIR)/man5/$$man; done for man in ${manfiles8}; do rm -f $(DESTDIR)$(MANDIR)/man8/$$man; done uninstall-doc: for doc in ${docfiles}; do rm -f $(DESTDIR)$(DOCDIR)/$$doc; done rm -rf --one-file-system $(DESTDIR)$(DOCDIR) uninstall: uninstall-man ifeq ($(HAVEDOC),yes) uninstall: uninstall-doc endif .PHONY: all man doc download-docs clean install install-man install-doc uninstall-man uninstall-doc uninstall cromerc-opensysusers-a12528f/man/UIDS-GIDS.md000066400000000000000000000450651431471057600206650ustar00rootroot00000000000000--- title: Users, Groups, UIDs and GIDs on systemd Systems category: Users, Groups and Home Directories layout: default SPDX-License-Identifier: LGPL-2.1-or-later --- # Users, Groups, UIDs and GIDs on systemd Systems Here's a summary of the requirements `systemd` (and Linux) make on UID/GID assignments and their ranges. Note that while in theory UIDs and GIDs are orthogonal concepts they really aren't IRL. With that in mind, when we discuss UIDs below it should be assumed that whatever we say about UIDs applies to GIDs in mostly the same way, and all the special assignments and ranges for UIDs always have mostly the same validity for GIDs too. ## Special Linux UIDs In theory, the range of the C type `uid_t` is 32bit wide on Linux, i.e. 0…4294967295. However, four UIDs are special on Linux: 1. 0 → The `root` super-user 2. 65534 → The `nobody` UID, also called the "overflow" UID or similar. It's where various subsystems map unmappable users to, for example file systems only supporting 16bit UIDs, NFS or user namespacing. (The latter can be changed with a sysctl during runtime, but that's not supported on `systemd`. If you do change it you void your warranty.) Because Fedora is a bit confused the `nobody` user is called `nfsnobody` there (and they have a different `nobody` user at UID 99). I hope this will be corrected eventually though. (Also, some distributions call the `nobody` group `nogroup`. I wish they didn't.) 3. 4294967295, aka "32bit `(uid_t) -1`" → This UID is not a valid user ID, as `setresuid()`, `chown()` and friends treat -1 as a special request to not change the UID of the process/file. This UID is hence not available for assignment to users in the user database. 4. 65535, aka "16bit `(uid_t) -1`" → Before Linux kernel 2.4 `uid_t` used to be 16bit, and programs compiled for that would hence assume that `(uid_t) -1` is 65535. This UID is hence not usable either. The `nss-systemd` glibc NSS module will synthesize user database records for the UIDs 0 and 65534 if the system user database doesn't list them. This means that any system where this module is enabled works to some minimal level without `/etc/passwd`. ## Special Distribution UID ranges Distributions generally split the available UID range in two: 1. 1…999 → System users. These are users that do not map to actual "human" users, but are used as security identities for system daemons, to implement privilege separation and run system daemons with minimal privileges. 2. 1000…65533 and 65536…4294967294 → Everything else, i.e. regular (human) users. Note that most distributions allow changing the boundary between system and regular users, even during runtime as user configuration. Moreover, some older systems placed the boundary at 499/500, or even 99/100. In `systemd`, the boundary is configurable only during compilation time, as this should be a decision for distribution builders, not for users. Moreover, we strongly discourage downstreams to change the boundary from the upstream default of 999/1000. Also note that programs such as `adduser` tend to allocate from a subset of the available regular user range only, usually 1000..60000. And it's also usually user-configurable, too. Note that systemd requires that system users and groups are resolvable without networking available — a requirement that is not made for regular users. This means regular users may be stored in remote LDAP or NIS databases, but system users may not (except when there's a consistent local cache kept, that is available during earliest boot, including in the initial RAM disk). ## Special `systemd` GIDs `systemd` defines no special UIDs beyond what Linux already defines (see above). However, it does define some special group/GID assignments, which are primarily used for `systemd-udevd`'s device management. The precise list of the currently defined groups is found in this `sysusers.d` snippet: [basic.conf](https://raw.githubusercontent.com/systemd/systemd/main/sysusers.d/basic.conf.in) It's strongly recommended that downstream distributions include these groups in their default group databases. Note that the actual GID numbers assigned to these groups do not have to be constant beyond a specific system. There's one exception however: the `tty` group must have the GID 5. That's because it must be encoded in the `devpts` mount parameters during earliest boot, at a time where NSS lookups are not possible. (Note that the actual GID can be changed during `systemd` build time, but downstreams are strongly advised against doing that.) ## Special `systemd` UID ranges `systemd` defines a number of special UID ranges: 1. 60001…60513 → UIDs for home directories managed by [`systemd-homed.service(8)`](https://www.freedesktop.org/software/systemd/man/systemd-homed.service.html). UIDs from this range are automatically assigned to any home directory discovered, and persisted locally on first login. On different systems the same user might get different UIDs assigned in case of conflict, though it is attempted to make UID assignments stable, by deriving them from a hash of the user name. 2. 61184…65519 → UIDs for dynamic users are allocated from this range (see the `DynamicUser=` documentation in [`systemd.exec(5)`](https://www.freedesktop.org/software/systemd/man/systemd.exec.html)). This range has been chosen so that it is below the 16bit boundary (i.e. below 65535), in order to provide compatibility with container environments that assign a 64K range of UIDs to containers using user namespacing. This range is above the 60000 boundary, so that its allocations are unlikely to be affected by `adduser` allocations (see above). And we leave some room upwards for other purposes. (And if you wonder why precisely these numbers: if you write them in hexadecimal, they might make more sense: 0xEF00 and 0xFFEF). The `nss-systemd` module will synthesize user records implicitly for all currently allocated dynamic users from this range. Thus, NSS-based user record resolving works correctly without those users being in `/etc/passwd`. 3. 524288…1879048191 → UID range for `systemd-nspawn`'s automatic allocation of per-container UID ranges. When the `--private-users=pick` switch is used (or `-U`) then it will automatically find a so far unused 16bit subrange of this range and assign it to the container. The range is picked so that the upper 16bit of the 32bit UIDs are constant for all users of the container, while the lower 16bit directly encode the 65536 UIDs assigned to the container. This mode of allocation means that the upper 16bit of any UID assigned to a container are kind of a "container ID", while the lower 16bit directly expose the container's own UID numbers. If you wonder why precisely these numbers, consider them in hexadecimal: 0x00080000…0x6FFFFFFF. This range is above the 16bit boundary. Moreover it's below the 31bit boundary, as some broken code (specifically: the kernel's `devpts` file system) erroneously considers UIDs signed integers, and hence can't deal with values above 2^31. The `systemd-machined.service` service will synthesize user database records for all UIDs assigned to a running container from this range. Note for both allocation ranges: when an UID allocation takes place NSS is checked for collisions first, and a different UID is picked if an entry is found. Thus, the user database is used as synchronization mechanism to ensure exclusive ownership of UIDs and UID ranges. To ensure compatibility with other subsystems allocating from the same ranges it is hence essential that they ensure that whatever they pick shows up in the user/group databases, either by providing an NSS module, or by adding entries directly to `/etc/passwd` and `/etc/group`. For performance reasons, do note that `systemd-nspawn` will only do an NSS check for the first UID of the range it allocates, not all 65536 of them. Also note that while the allocation logic is operating, the glibc `lckpwdf()` user database lock is taken, in order to make this logic race-free. ## Figuring out the system's UID boundaries The most important boundaries of the local system may be queried with `pkg-config`: ``` $ pkg-config --variable=systemuidmax systemd 999 $ pkg-config --variable=dynamicuidmin systemd 61184 $ pkg-config --variable=dynamicuidmax systemd 65519 $ pkg-config --variable=containeruidbasemin systemd 524288 $ pkg-config --variable=containeruidbasemax systemd 1878982656 ``` (Note that the latter encodes the maximum UID *base* `systemd-nspawn` might pick — given that 64K UIDs are assigned to each container according to this allocation logic, the maximum UID used for this range is hence 1878982656+65535=1879048191.) Systemd has compile-time default for these boundaries. Using those defaults is recommended. It will nevertheless query `/etc/login.defs` at runtime, when compiled with `-Dcompat-mutable-uid-boundaries=true` and that file is present. Support for this is considered only a compatibility feature and should not be used except when upgrading systems which were created with different defaults. ## Considerations for container managers If you hack on a container manager, and wonder how and how many UIDs best to assign to your containers, here are a few recommendations: 1. Definitely, don't assign less than 65536 UIDs/GIDs. After all the `nobody` user has magic properties, and hence should be available in your container, and given that it's assigned the UID 65534, you should really cover the full 16bit range in your container. Note that systemd will — as mentioned — synthesize user records for the `nobody` user, and assumes its availability in various other parts of its codebase, too, hence assigning fewer users means you lose compatibility with running systemd code inside your container. And most likely other packages make similar restrictions. 2. While it's fine to assign more than 65536 UIDs/GIDs to a container, there's most likely not much value in doing so, as Linux distributions won't use the higher ranges by default (as mentioned neither `adduser` nor `systemd`'s dynamic user concept allocate from above the 16bit range). Unless you actively care for nested containers, it's hence probably a good idea to allocate exactly 65536 UIDs per container, and neither less nor more. A pretty side-effect is that by doing so, you expose the same number of UIDs per container as Linux 2.2 supported for the whole system, back in the days. 3. Consider allocating UID ranges for containers so that the first UID you assign has the lower 16bits all set to zero. That way, the upper 16bits become a container ID of some kind, while the lower 16bits directly encode the internal container UID. This is the way `systemd-nspawn` allocates UID ranges (see above). Following this allocation logic ensures best compatibility with `systemd-nspawn` and all other container managers following the scheme, as it is sufficient then to check NSS for the first UID you pick regarding conflicts, as that's what they do, too. Moreover, it makes `chown()`ing container file system trees nicely robust to interruptions: as the external UID encodes the internal UID in a fixed way, it's very easy to adjust the container's base UID without the need to know the original base UID: to change the container base, just mask away the upper 16bit, and insert the upper 16bit of the new container base instead. Here are the easy conversions to derive the internal UID, the external UID, and the container base UID from each other: ``` INTERNAL_UID = EXTERNAL_UID & 0x0000FFFF CONTAINER_BASE_UID = EXTERNAL_UID & 0xFFFF0000 EXTERNAL_UID = INTERNAL_UID | CONTAINER_BASE_UID ``` 4. When picking a UID range for containers, make sure to check NSS first, with a simple `getpwuid()` call: if there's already a user record for the first UID you want to pick, then it's already in use: pick a different one. Wrap that call in a `lckpwdf()` + `ulckpwdf()` pair, to make allocation race-free. Provide an NSS module that makes all UIDs you end up taking show up in the user database, and make sure that the NSS module returns up-to-date information before you release the lock, so that other system components can safely use the NSS user database as allocation check, too. Note that if you follow this scheme no changes to `/etc/passwd` need to be made, thus minimizing the artifacts the container manager persistently leaves in the system. 5. `systemd-homed` by default mounts the home directories it manages with UID mapping applied. It will map four UID ranges into that uidmap, and leave everything else unmapped: the range from 0…60000, the user's own UID, the range 60514…65534, and the container range 524288…1879048191. This means files/directories in home directories managed by `systemd-homed` cannot be owned by UIDs/GIDs outside of these four ranges (attempts to `chown()` files to UIDs outside of these ranges will fail). Thus, if container trees are to be placed within a home directory managed by `systemd-homed` they should take these ranges into consideration and either place the trees at base UID 0 (and then map them to a higher UID range for use in user namespacing via another level of UID mapped mounts, at *runtime*) or at a base UID from the container UID range. That said, placing container trees (and in fact any files/directories not owned by the home directory's user) in home directories is generally a questionable idea (regardless of whether `systemd-homed` is used or not), given this typically breaks quota assumptions, makes it impossible for users to properly manage all files in their own home directory due to permission problems, introduces security issues around SETUID and severely restricts compatibility with networked home directories. Typically, it's a much better idea to place container images outside of the home directory, i.e. somewhere below `/var/` or similar. ## Summary | UID/GID | Purpose | Defined By | Listed in | |-----------------------|-----------------------|---------------|-------------------------------| | 0 | `root` user | Linux | `/etc/passwd` + `nss-systemd` | | 1…4 | System users | Distributions | `/etc/passwd` | | 5 | `tty` group | `systemd` | `/etc/passwd` | | 6…999 | System users | Distributions | `/etc/passwd` | | 1000…60000 | Regular users | Distributions | `/etc/passwd` + LDAP/NIS/… | | 60001…60513 | Human users (homed) | `systemd` | `nss-systemd` | | 60514…60577 | Host users mapped into containers | `systemd` | `systemd-nspawn` | | 60578…61183 | Unused | | | | 61184…65519 | Dynamic service users | `systemd` | `nss-systemd` | | 65520…65533 | Unused | | | | 65534 | `nobody` user | Linux | `/etc/passwd` + `nss-systemd` | | 65535 | 16bit `(uid_t) -1` | Linux | | | 65536…524287 | Unused | | | | 524288…1879048191 | Container UID ranges | `systemd` | `nss-systemd` | | 1879048192…2147483647 | Unused | | | | 2147483648…4294967294 | HIC SVNT LEONES | | | | 4294967295 | 32bit `(uid_t) -1` | Linux | | Note that "Unused" in the table above doesn't mean that these ranges are really unused. It just means that these ranges have no well-established pre-defined purposes between Linux, generic low-level distributions and `systemd`. There might very well be other packages that allocate from these ranges. Note that the range 2147483648…4294967294 (i.e. 2^31…2^32-2) should be handled with care. Various programs (including kernel file systems — see `devpts` — or even kernel syscalls – see `setfsuid()`) have trouble with UIDs outside of the signed 32bit range, i.e any UIDs equal to or above 2147483648. It is thus strongly recommended to stay away from this range in order to avoid complications. This range should be considered reserved for future, special purposes. ## Notes on resolvability of user and group names User names, UIDs, group names and GIDs don't have to be resolvable using NSS (i.e. getpwuid() and getpwnam() and friends) all the time. However, systemd makes the following requirements: System users generally have to be resolvable during early boot already. This means they should not be provided by any networked service (as those usually become available during late boot only), except if a local cache is kept that makes them available during early boot too (i.e. before networking is up). Specifically, system users need to be resolvable at least before `systemd-udevd.service` and `systemd-tmpfiles.service` are started, as both need to resolve system users — but note that there might be more services requiring full resolvability of system users than just these two. Regular users do not need to be resolvable during early boot, it is sufficient if they become resolvable during late boot. Specifically, regular users need to be resolvable at the point in time the `nss-user-lookup.target` unit is reached. This target unit is generally used as synchronization point between providers of the user database and consumers of it. Services that require that the user database is fully available (for example, the login service `systemd-logind.service`) are ordered *after* it, while services that provide parts of the user database (for example an LDAP user database client) are ordered *before* it. Note that `nss-user-lookup.target` is a *passive* unit: in order to minimize synchronization points on systems that don't need it the unit is pulled into the initial transaction only if there's at least one service that really needs it, and that means only if there's a service providing the local user database somehow through IPC or suchlike. Or in other words: if you hack on some networked user database project, then make sure you order your service `Before=nss-user-lookup.target` and that you pull it in with `Wants=nss-user-lookup.target`. However, if you hack on some project that needs the user database to be up in full, then order your service `After=nss-user-lookup.target`, but do *not* pull it in via a `Wants=` dependency. cromerc-opensysusers-a12528f/man/USER_NAMES.md000066400000000000000000000205051431471057600210660ustar00rootroot00000000000000--- title: User/Group Name Syntax category: Users, Groups and Home Directories layout: default SPDX-License-Identifier: LGPL-2.1-or-later --- # User/Group Name Syntax The precise set of allowed user and group names on Linux systems is weakly defined. Depending on the distribution a different set of requirements and restrictions on the syntax of user/group names are enforced — on some distributions the accepted syntax is even configurable by the administrator. In the interest of interoperability systemd enforces different rules when processing users/group defined by other subsystems and when defining users/groups itself, following the principle of "Be conservative in what you send, be liberal in what you accept". Also in the interest of interoperability systemd will enforce the same rules everywhere and not make them configurable or distribution dependent. The precise rules are described below. Generally, the same rules apply for user as for group names. ## Other Systems * On POSIX the set of [valid user names](https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_437) is defined as [lower and upper case ASCII letters, digits, period, underscore, and hyphen](https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_282), with the restriction that hyphen is not allowed as first character of the user name. Interestingly no size limit is declared, i.e. in neither direction, meaning that strictly speaking according to POSIX both the empty string is a valid user name as well as a string of gigabytes in length. * Debian/Ubuntu based systems enforce the regular expression `^[a-z][-a-z0-9]*$`, i.e. only lower case ASCII letters, digits and hyphens. As first character only lowercase ASCII letters are allowed. This regular expression is configurable by the administrator at runtime though. This rule enforces a minimum length of one character but no maximum length. * Upstream shadow-utils enforces the regular expression `^[a-z_][a-z0-9_-]*[$]$`, i.e. is similar to the Debian/Ubuntu rule, but allows underscores and hyphens, but the latter not as first character. Also, an optional trailing dollar character is permitted. * Fedora/Red Hat based systems enforce the regular expression of `^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,30}[a-zA-Z0-9_.$-]?$`, i.e. a size limit of 32 characters, with upper and lower case letters, digits, underscores, hyphens and periods. No hyphen as first character though, and the last character may be a dollar character. On top of that, `.` and `..` are not allowed as user/group names. * sssd is known to generate user names with embedded `@` and white-space characters, as well as non-ASCII (i.e. UTF-8) user/group names. * winbindd is known to generate user/group names with embedded `\` and white-space characters, as well as non-ASCII (i.e. UTF-8) user/group names. Other operating systems enforce different rules; in this documentation we'll focus on Linux systems only however, hence those are out of scope. That said, software like Samba is frequently deployed on Linux for providing compatibility with Windows systems; on such systems it might be wise to stick to user/group names also valid according to Windows rules. ## Rules systemd enforces Distilled from the above, below are the rules systemd enforces on user/group names. An additional, common rule between both modes listed below is that empty strings are not valid user/group names. Philosophically, the strict mode described below enforces an allow list of what's allowed and prohibits everything else, while the relaxed mode described below implements a deny list of what's not allowed and permits everything else. ### Strict mode Strict user/group name syntax is enforced whenever a systemd component is used to register a user or group in the system, for example a system user/group using [`systemd-sysusers.service`](https://www.freedesktop.org/software/systemd/man/systemd-sysusers.html) or a regular user with [`systemd-homed.service`](https://www.freedesktop.org/software/systemd/man/systemd-homed.html). In strict mode, only uppercase and lowercase characters are allowed, as well as digits, underscores and hyphens. The first character may not be a digit or hyphen. A size limit is enforced: the minimum of `sysconf(_SC_LOGIN_NAME_MAX)` (typically 256 on Linux; rationale: this is how POSIX suggests to detect the limit), `UT_NAMESIZE-1` (typically 31 on Linux; rationale: names longer than this cannot correctly appear in `utmp`/`wtmp` and create ambiguity with login accounting) and `NAME_MAX` (255 on Linux; rationale: user names typically appear in directory names, i.e. the home directory), thus MIN(256, 31, 255) = 31. Note that these rules are both more strict and more relaxed than all of the rules enforced by other systems listed above. A user/group name conforming to systemd's strict rules will not necessarily pass a test by the rules enforced by these other subsystems. Written as regular expression the above is: `^[a-zA-Z_][a-zA-Z0-9_-]{0,30}$` ### Relaxed mode Relaxed user/group name syntax is enforced whenever a systemd component accepts and makes use of user/group names registered by other (non-systemd) components of the system, for example in [`systemd-logind.service`](https://www.freedesktop.org/software/systemd/man/systemd-logind.html). Relaxed syntax is also enforced by the `User=` setting in service unit files, i.e. for system services used for running services. Since these users may be registered by a variety of tools relaxed mode is used, but since the primary purpose of these users is to run a system service and thus a job for systemd a warning is shown if the specified user name does not qualify by the strict rules above. * No embedded NUL bytes (rationale: handling in C must be possible and straightforward) * No names consisting fully of digits (rationale: avoid confusion with numeric UID/GID specifications) * Similar, no names consisting of an initial hyphen and otherwise entirely made up of digits (rationale: avoid confusion with negative, numeric UID/GID specifications, e.g. `-1`) * No strings that do not qualify as valid UTF-8 (rationale: we want to be able to embed these strings in JSON, with permits only valid UTF-8 in its strings; user names using other character sets, such as JIS/Shift-JIS will cause validation errors) * No control characters (i.e. characters in ASCII range 1…31; rationale: they tend to have special meaning when output on a terminal in other contexts, moreover the newline character — as a specific control character — is used as record separator in `/etc/passwd`, and hence it's crucial to avoid ambiguities here) * No colon characters (rationale: it is used as field separator in `/etc/passwd`) * The two strings `.` and `..` are not permitted, as these have special meaning in file system paths, and user names are frequently included in file system paths, in particular for the purpose of home directories. * Similar, no slashes, as these have special meaning in file system paths * No leading or trailing white-space is permitted; and hence no user/group names consisting of white-space only either (rationale: this typically indicates parsing errors, and creates confusion since not visible on screen) Note that these relaxed rules are implied by the strict rules above, i.e. all user/group names accepted by the strict rules are also accepted by the relaxed rules, but not vice versa. Note that this relaxed mode does not refuse a couple of very questionable syntaxes. For example it permits a leading or embedded period. A leading period is problematic because the matching home directory would typically be hidden from the user's/administrator's view. An embedded period is problematic since it creates ambiguity in traditional `chown` syntax (which is still accepted today) that uses it to separate user and group names in the command's parameter: without consulting the user/group databases it is not possible to determine if a `chown` invocation would change just the owning user or both the owning user and group. It also allows embedding `@` (which is confusing to MTAs). ## Common Core Combining all rules listed above, user/group names that shall be considered valid in all systemd contexts and on all Linux systems should match the following regular expression (at least according to our understanding): `^[a-z][a-z0-9-]{0,30}$` cromerc-opensysusers-a12528f/man/custom-html.xsl000066400000000000000000000275031431471057600220540ustar00rootroot00000000000000 .html# https://man7.org/linux/man-pages/man / . .html http://linux.die.net/man/ / https://git.zx2c4.com/WireGuard/about/src/tools/ . https://www.mankier.com/ / https://www.archlinux.org/ / . .html https://manpages.debian.org/unstable/ / . .en.html https://www.freebsd.org/cgi/man.cgi? ( ) https://dbus.freedesktop.org/doc/ . .html
index.html Index · systemd.directives.html Directives systemd
" " cromerc-opensysusers-a12528f/man/custom-man.xsl000066400000000000000000000027511431471057600216610ustar00rootroot00000000000000 .TH " " " " "" "systemd " " " " " cromerc-opensysusers-a12528f/man/standard-options.xml000066400000000000000000000061321431471057600230560ustar00rootroot00000000000000 Print a short help text and exit. Print a short version string and exit. Do not pipe output into a pager. Do not query the user for authentication for privileged operations. BOOL Enable or disable printing of the legend, i.e. column headers and the footer with hints. The legend is printed by default, unless disabled with or similar. Do not print the legend, i.e. column headers and the footer with hints. Copy the contents of config files to standard output. Before each file, the filename is printed as a comment. MODE Shows output formatted as JSON. Expects one of short (for the shortest possible output without any redundant whitespace or line breaks), pretty (for a pretty version of the same, with indentation and line breaks) or off (to turn off JSON output, the default). When used with kill, choose which signal to send to selected processes. Must be one of the well-known signal specifiers such as SIGTERM, SIGINT or SIGSTOP. If omitted, defaults to . The special value help will list the known values and the program will exit immediately, and the special value list will list known values along with the numerical signal numbers and the program will exit immediately. cromerc-opensysusers-a12528f/man/standard-specifiers.xml000066400000000000000000000135271431471057600235250ustar00rootroot00000000000000 %a Architecture A short string identifying the architecture of the local system. A string such as x86, x86-64 or arm64. See the architectures defined for ConditionArchitecture= in systemd.unit5 for a full list. %A Operating system image version The operating system image version identifier of the running system, as read from the IMAGE_VERSION= field of /etc/os-release. If not set, resolves to an empty string. See os-release5 for more information. %b Boot ID The boot ID of the running system, formatted as string. See random4 for more information. %B Operating system build ID The operating system build identifier of the running system, as read from the BUILD_ID= field of /etc/os-release. If not set, resolves to an empty string. See os-release5 for more information. %H Host name The hostname of the running system. %l Short host name The hostname of the running system, truncated at the first dot to remove any domain component. %m Machine ID The machine ID of the running system, formatted as string. See machine-id5 for more information. %M Operating system image identifier The operating system image identifier of the running system, as read from the IMAGE_ID= field of /etc/os-release. If not set, resolves to an empty string. See os-release5 for more information. %o Operating system ID The operating system identifier of the running system, as read from the ID= field of /etc/os-release. See os-release5 for more information. %q Pretty host name The pretty hostname of the running system, as read from the PRETTY_HOSTNAME= field of /etc/machine-info. If not set, resolves to the short hostname. See machine-info5 for more information. %T Directory for temporary files This is either /tmp or the path $TMPDIR, $TEMP or $TMP are set to. (Note that the directory may be specified without a trailing slash.) %v Kernel release Identical to uname -r output. %V Directory for larger and persistent temporary files This is either /var/tmp or the path $TMPDIR, $TEMP or $TMP are set to. (Note that the directory may be specified without a trailing slash.) %w Operating system version ID The operating system version identifier of the running system, as read from the VERSION_ID= field of /etc/os-release. If not set, resolves to an empty string. See os-release5 for more information. %W Operating system variant ID The operating system variant identifier of the running system, as read from the VARIANT_ID= field of /etc/os-release. If not set, resolves to an empty string. See os-release5 for more information. %% Single percent sign Use %% in place of % to specify a single percent sign. cromerc-opensysusers-a12528f/man/systemd-sysusers.xml000066400000000000000000000251721431471057600231600ustar00rootroot00000000000000 systemd-sysusers systemd systemd-sysusers 8 systemd-sysusers systemd-sysusers.service Allocate system users and groups systemd-sysusers OPTIONS CONFIGFILE systemd-sysusers.service Description systemd-sysusers creates system users and groups, based on files in the format described in sysusers.d5. If invoked with no arguments, it applies all directives from all files found in the directories specified by sysusers.d5. When invoked with positional arguments, if option is specified, arguments specified on the command line are used instead of the configuration file PATH. Otherwise, just the configuration specified by the command line arguments is executed. The string - may be specified instead of a filename to instruct systemd-sysusers to read the configuration from standard input. If the argument is a relative path, all configuration directories are searched for a matching file and the file found that has the highest priority is executed. If the argument is an absolute path, that file is used directly without searching of the configuration directories. Options The following options are understood: Takes a directory path as an argument. All paths will be prefixed with the given alternate root path, including config search paths. Takes a path to a disk image file or block device node. If specified all operations are applied to file system in the indicated disk image. This is similar to but operates on file systems stored in disk images or block devices. The disk image should either contain just a file system or a set of file systems within a GPT partition table, following the Discoverable Partitions Specification. For further information on supported disk images, see systemd-nspawn1's switch of the same name. When this option is given, one or more positional arguments must be specified. All configuration files found in the directories listed in sysusers.d5 will be read, and the configuration given on the command line will be handled instead of and with the same priority as the configuration file PATH. This option is intended to be used when package installation scripts are running and files belonging to that package are not yet available on disk, so their contents must be given on the command line, but the admin configuration might already exist and should be given higher priority. RPM installation script for radvd echo 'u radvd - "radvd daemon"' | \ systemd-sysusers --replace=/usr/lib/sysusers.d/radvd.conf - This will create the radvd user as if /usr/lib/sysusers.d/radvd.conf was already on disk. An admin might override the configuration specified on the command line by placing /etc/sysusers.d/radvd.conf or even /etc/sysusers.d/00-overrides.conf. Note that this is the expanded form, and when used in a package, this would be written using a macro with "radvd" and a file containing the configuration line as arguments. Process the configuration and figure out what entries would be created, but don't actually write anything. Treat each positional argument as a separate configuration line instead of a file name. Credentials systemd-sysusers supports the service credentials logic as implemented by LoadCredential=/SetCredential= (see systemd.exec1 for details). The following credentials are used when passed in: passwd.hashed-password.user A UNIX hashed password string to use for the specified user, when creating an entry for it. This is particularly useful for the root user as it allows provisioning the default root password to use via a unit file drop-in or from a container manager passing in this credential. Note that setting this credential has no effect if the specified user account already exists. This credential is hence primarily useful in first boot scenarios or systems that are fully stateless and come up with an empty /etc/ on every boot. passwd.plaintext-password.user Similar to passwd.hashed-password.user but expect a literal, plaintext password, which is then automatically hashed before used for the user account. If both the hashed and the plaintext credential are specified for the same user the former takes precedence. It's generally recommended to specify the hashed version; however in test environments with weaker requirements on security it might be easier to pass passwords in plaintext instead. passwd.shell.user Specifies the shell binary to use for the specified account when creating it. sysusers.extra The contents of this credential may contain additional lines to operate on. The credential contents should follow the same format as any other sysusers.d/ drop-in. If this credential is passed it is processed after all of the drop-in files read from the file system. Note that by default the systemd-sysusers.service unit file is set up to inherit the passwd.hashed-password.root, passwd.plaintext-password.root, passwd.shell.root and sysusers.extra credentials from the service manager. Thus, when invoking a container with an unpopulated /etc/ for the first time it is possible to configure the root user's password to be systemd like this: # systemd-nspawn --image=… --set-credential=passwd.hashed-password.root:'$y$j9T$yAuRJu1o5HioZAGDYPU5d.$F64ni6J2y2nNQve90M/p0ZP0ECP/qqzipNyaY9fjGpC' … Note again that the data specified in this credential is consulted only when creating an account for the first time, it may not be used for changing the password or shell of an account that already exists. Use mkpasswd1 for generating UNIX password hashes from the command line. Exit status On success, 0 is returned, a non-zero failure code otherwise. See Also systemd1, sysusers.d5, Users, Groups, UIDs and GIDs on systemd systems, systemd.exec1, mkpasswd1 cromerc-opensysusers-a12528f/man/sysusers.d.xml000066400000000000000000000317301431471057600217110ustar00rootroot00000000000000 sysusers.d systemd sysusers.d 5 sysusers.d Declarative allocation of system users and groups /etc/sysusers.d/*.conf /run/sysusers.d/*.conf /usr/lib/sysusers.d/*.conf #Type Name ID GECOS Home directory Shell u user_name uid "User Description" /home/dir /path/to/shell u user_name uid:gid "User Description" /home/dir /path/to/shell u user_name /file/owned/by/user "User Description" /home/dir /path/to/shell g group_name gid g group_name /file/owned/by/group m user_name group_name r - lowest-highest Description systemd-sysusers uses the files from sysusers.d directory to create system users and groups and to add users to groups, at package installation or boot time. This tool may be used to allocate system users and groups only, it is not useful for creating non-system (i.e. regular, "human") users and groups, as it accesses /etc/passwd and /etc/group directly, bypassing any more complex user databases, for example any database involving NIS or LDAP. Configuration Directories and Precedence Each configuration file shall be named in the style of package.conf or package-part.conf. The second variant should be used when it is desirable to make it easy to override just this part of configuration. Files in /etc/sysusers.d override files with the same name in /usr/lib/sysusers.d and /run/sysusers.d. Files in /run/sysusers.d override files with the same name in /usr/lib/sysusers.d. Packages should install their configuration files in /usr/lib/sysusers.d. Files in /etc/sysusers.d are reserved for the local administrator, who may use this logic to override the configuration files installed by vendor packages. All configuration files are sorted by their filename in lexicographic order, regardless of which of the directories they reside in. If multiple files specify the same path, the entry in the file with the lexicographically earliest name will be applied. All later entries for the same user and group names will be logged as warnings. If the administrator wants to disable a configuration file supplied by the vendor, the recommended way is to place a symlink to /dev/null in /etc/sysusers.d/ bearing the same filename. Configuration File Format The file format is one line per user or group containing name, ID, GECOS field description, home directory, and login shell: #Type Name ID GECOS Home directory Shell u httpd 404 "HTTP User" u _authd /usr/bin/authd "Authorization user" u postgres - "Postgresql Database" /var/lib/pgsql /usr/libexec/postgresdb g input - - m _authd input u root 0 "Superuser" /root /bin/zsh r - 500-900 Empty lines and lines beginning with the # character are ignored, and may be used for commenting. Type The type consists of a single letter. The following line types are understood: u Create a system user and group of the specified name should they not exist yet. The user's primary group will be set to the group bearing the same name unless the ID field specifies it. The account will be created disabled, so that logins are not allowed. g Create a system group of the specified name should it not exist yet. Note that u implicitly creates a matching group. The group will be created with no password set. m Add a user to a group. If the user or group do not exist yet, they will be implicitly created. r Add a range of numeric UIDs/GIDs to the pool to allocate new UIDs and GIDs from. If no line of this type is specified, the range of UIDs/GIDs is set to some compiled-in default. Note that both UIDs and GIDs are allocated from the same pool, in order to ensure that users and groups of the same name are likely to carry the same numeric UID and GID. Name The name field specifies the user or group name. The specified name must consist only of the characters a-z, A-Z, 0-9, _ and -, except for the first character which must be one of a-z, A-Z or _ (i.e. numbers and - are not permitted as first character). The user/group name must have at least one character, and at most 31. For further details about the syntax of user/group names, see User/Group Name Syntax. It is strongly recommended to pick user and group names that are unlikely to clash with normal users created by the administrator. A good scheme to guarantee this is by prefixing all system and group names with the underscore, and avoiding too generic names. For m lines, this field should contain the user name to add to a group. For lines of type r, this field should be set to -. ID For u and g, the numeric 32-bit UID or GID of the user/group. Do not use IDs 65535 or 4294967295, as they have special placeholder meanings. Specify - for automatic UID/GID allocation for the user or group (this is strongly recommended unless it is strictly necessary to use a specific UID or GID). Alternatively, specify an absolute path in the file system. In this case, the UID/GID is read from the path's owner/group. This is useful to create users whose UID/GID match the owners of pre-existing files (such as SUID or SGID binaries). The syntaxes uid:gid and uid:groupname are supported to allow creating users with specific primary groups. The given group must be created explicitly, or it must already exist. Specifying - for the UID in these syntaxes is also supported. For m lines, this field should contain the group name to add to a user to. For lines of type r, this field should be set to a UID/GID range in the format FROM-TO, where both values are formatted as decimal ASCII numbers. Alternatively, a single UID/GID may be specified formatted as decimal ASCII numbers. GECOS A short, descriptive string for users to be created, enclosed in quotation marks. Note that this field may not contain colons. Only applies to lines of type u and should otherwise be left unset (or -). Home Directory The home directory for a new system user. If omitted, defaults to the root directory. Only applies to lines of type u and should otherwise be left unset (or -). It is recommended to omit this, unless software strictly requires a home directory to be set. systemd-sysusers only sets the home directory record in the user database. To actually create the directory, consider adding a corresponding tmpfiles.d5 fragment. Shell The login shell of the user. If not specified, this will be set to /usr/sbin/nologin, except if the UID of the user is 0, in which case /bin/sh will be used. Only applies to lines of type u and should otherwise be left unset (or -). It is recommended to omit this, unless a shell different /usr/sbin/nologin must be used. Specifiers Specifiers can be used in the Name, ID, GECOS, Home directory, and Shell fields. An unknown or unresolvable specifier is treated as invalid configuration. The following expansions are understood: Specifiers available Specifier Meaning Details
Idempotence Note that systemd-sysusers will do nothing if the specified users or groups already exist or the users are members of specified groups, so normally there is no reason to override sysusers.d vendor configuration, except to block certain users or groups from being created. See Also systemd1, systemd-sysusers8 cromerc-opensysusers-a12528f/openrc/000077500000000000000000000000001431471057600175545ustar00rootroot00000000000000cromerc-opensysusers-a12528f/openrc/opensysusers.initd.in000066400000000000000000000003701431471057600237740ustar00rootroot00000000000000#!/sbin/openrc-run # Copyright (c) 2017 - 2018 Chris Cromer # Released under the 2-clause BSD license. description="Set up sysusers.d entries" depend() { need localmount } start() { ebegin "Setting up sysusers.d entries" @BINNAME@ eend $? } cromerc-opensysusers-a12528f/sysusers000077500000000000000000000121151431471057600201140ustar00rootroot00000000000000#!/bin/sh # Copyright (c) 2018 - 2022 Chris Cromer # Released under the 2-clause BSD license. # # This is an implementation of the systemd-sysusers command sysusersver=0.7.3 warninvalid() { printf "sysusers: %s on line %d of '%s'\n" "${1:-ignoring invalid entry}" \ "${lineno}" "${file}" : "$((error += 1))" } >&2 add_group() { # add_group if [ "$2" = '-' ]; then grep -q "^$1:" /etc/group || groupadd -r "$1" elif ! grep -q "^$1:\|^[^:]*:[^:]*:$2:[^:]*$" /etc/group; then groupadd -g "$2" "$1" fi } add_user() { # add_user if ! id "$1" >/dev/null 2>&1; then if [ "$2" = '-' ]; then useradd -rc "$3" -g "$1" -d "$4" -s '/sbin/nologin' "$1" else useradd -rc "$3" -u "$2" -g "$1" -d "$4" -s '/sbin/nologin' "$1" fi passwd -l "$1" >/dev/null 2>&1 fi } update_login_defs() { # update_login_defs [ "$1" != '-' ] && warninvalid && return min="${2%%-*}" max="${2#*-}" [ "${max}" != "${max#*-}" ] && warninvalid && return [ "${min}" -ge "${max}" ] && warninvalid "invalid range" && return while read -r key val; do case "${key}" in SYS_UID_MAX) suid_max="${val}" ;; SYS_GID_MAX) sgid_max="${val}" ;; esac done < "${root}/etc/login.defs" [ "${min}" -lt "${suid_max}" ] && warninvalid "invalid range" && return [ "${min}" -lt "${sgid_max}" ] && warninvalid "invalid range" && return sed -e "/[GU]ID_MIN[[:space:]]\+/s/[^[:space:]]*$/${min}/" \ -e "/[GU]ID_MAX[[:space:]]\+/s/[^[:space:]]*$/${max}/" \ -i "${root}/etc/login.defs" } parse_file() { while read -r conf; do lineno=0 while read -r line; do parse_string "${line}" "$((lineno += 1))" done < "${conf}" [ -n "${line}" ] && parse_string "${line}" done } parse_string() { [ -n "${1%%#*}" ] || return full_line=$1 #eval "set -- $1" # do not use eval, see CVE-2021-40084 set -- $1 type="$1" name="$2" id="$3" gecos="$4" home="$5" # and now set the GECOS field without eval if [ "${type}" = u ]; then if [ ! -z "$4" ] && [ "$4" != '-' ]; then # strip everything before the first " gecosplus=${full_line#*\"} # now strip everything after the last " gecos=${gecosplus%\"*} # check if there are other valid fields after GECOS gecostest=$(echo $gecosplus | grep -o '".*' -) if [ "$gecostest" = '"' ]; then home= else set -- $gecostest home=$2 fi fi fi case "${type}" in [gu]) case "${id}" in 65535|4294967295) warninvalid; return; esac [ "${home:--}" = '-' ] && home='/' add_group "${name}" "${id}" if [ "${type}" = u ]; then add_user "${name}" "${id}" "${gecos}" "${home}" fi ;; m) add_group "${id}" '-' if id "${name}" >/dev/null 2>&1; then usermod -a -G "${id}" "${name}" else useradd -r -g "${id}" -s '/sbin/nologin' "${name}" passwd -l "${name}" >/dev/null 2>&1 fi ;; r) update_login_defs "${name}" "${id}" ;; *) warninvalid; return ;; esac } usage() { printf '%s\n' \ "${0##*/}" '' \ "${0##*/} creates system users and groups, based on the file" \ 'format and location specified in sysusers.d(5).' '' \ "Usage: ${0##*/} [OPTIONS...] [CONFIGFILE...]" '' \ 'Options:' \ ' --root=root All paths will be prefixed with the' \ ' given alternate root path, including' \ ' config search paths.' \ " --replace=PATH Don't run check in the package" \ ' --inline Treat each positional argument as a' \ ' separate configuration line instead of a' \ ' file name.' \ ' -h, --help Print a short help text and exit.' \ ' --version Print a short version string and exit.' exit "$1" } error=0 inline=0 replace='' root='' seen='' # opensysusers is an implementation of sysusers.d spec without # systemd command, it doesn't accept options or arguments [ "${0##*/}" = opensysusers ] && set -- while [ "$#" -ne 0 ]; do case "$1" in --root=*) root="${1#--root=}" ;; --root) root="$2"; shift ;; --replace=*) replace="${1#--replace=}" ;; --replace) replace="$2"; shift ;; --inline) inline=1 ;; --version) printf '%s\n' "${sysusersver}"; exit 0 ;; -h|--help) usage 0 ;; -[!-]|--?*) usage 1 ;; --) shift; break ;; *) break ;; esac shift done if [ "${inline}" -eq 0 ]; then for file do [ "${file}" = '--' ] && continue for dir in etc run usr/lib; do if [ -f "${root}/${dir}/sysusers.d/${file}" ]; then sed -i -e '$a\' "${root}/${dir}/sysusers.d/${file}" printf '%s/%s/sysusers.d/%s\n' "${root}" "${dir}" "${file}" | parse_file break fi done done else for string in "$@"; do parse_string "${string}" done fi if [ "$#" -eq 0 ] || [ -n "${replace}" ]; then set -- "${root}/etc/sysusers.d/"*.conf "${root}/run/sysusers.d/"*.conf \ "${root}/usr/lib/sysusers.d/"*.conf for f do printf '%s %s\n' "${f##*/}" "${f%/*}"; done | sort -k1,1 | while read -r b d; do [ "${seen}" = "${seen#* ${b} }" ] && [ -f "${d}/${b}" ] && { seen="${seen:- }${b} "; printf '%s/%s\n' "${d}" "${b}"; } done | parse_file fi exit "${error}" cromerc-opensysusers-a12528f/test/000077500000000000000000000000001431471057600172455ustar00rootroot00000000000000cromerc-opensysusers-a12528f/test/amavisd.conf000066400000000000000000000000411431471057600215330ustar00rootroot00000000000000u amavis 333 - /var/spool/amavis cromerc-opensysusers-a12528f/test/amule.conf000066400000000000000000000000621431471057600212150ustar00rootroot00000000000000u amule - "aMule Client" /var/lib/amule g amule - cromerc-opensysusers-a12528f/test/backuppc.conf000066400000000000000000000000431431471057600217010ustar00rootroot00000000000000u backuppc 126 - /var/lib/backuppc cromerc-opensysusers-a12528f/test/boinc.conf000066400000000000000000000000611431471057600212030ustar00rootroot00000000000000u boinc - "BOINC Daemon" /var/lib/boinc g boinc -cromerc-opensysusers-a12528f/test/ceph.conf000066400000000000000000000000251431471057600210300ustar00rootroot00000000000000u ceph - - /run/ceph cromerc-opensysusers-a12528f/test/couchdb.conf000066400000000000000000000000561431471057600215240ustar00rootroot00000000000000u couchdb - "CouchDB daemon" /var/lib/couchdb cromerc-opensysusers-a12528f/test/dbus.conf000066400000000000000000000000121431471057600210420ustar00rootroot00000000000000u dbus 81 cromerc-opensysusers-a12528f/test/deepin-daemon.conf000066400000000000000000000000641431471057600226210ustar00rootroot00000000000000u deepin-daemon - "Deepin Daemon" g deepin-daemon - cromerc-opensysusers-a12528f/test/dkimproxy.conf000066400000000000000000000000331431471057600221360ustar00rootroot00000000000000u dkimproxy - "DKIM Proxy" cromerc-opensysusers-a12528f/test/dnscrypt-wrapper.conf000066400000000000000000000001231431471057600234340ustar00rootroot00000000000000u dnscrypt-wrapper - "DnsCrypt Wrapper" /etc/dnscrypt-wrapper g dnscrypt-wrapper - cromerc-opensysusers-a12528f/test/dnsmasq.conf000066400000000000000000000000371431471057600215620ustar00rootroot00000000000000u dnsmasq - "dnsmasq daemon" / cromerc-opensysusers-a12528f/test/docker.conf000066400000000000000000000000561431471057600213640ustar00rootroot00000000000000# create docker group (FS#38029) g docker - - cromerc-opensysusers-a12528f/test/fetchmail.conf000066400000000000000000000001101431471057600220400ustar00rootroot00000000000000u fetchmail 90 "Fetchmail daemon" /var/lib/fetchmail m fetchmail nobody cromerc-opensysusers-a12528f/test/filebeat.conf000066400000000000000000000001021431471057600216600ustar00rootroot00000000000000u filebeat - "Lightweight Shipper for Log Data" /var/lib/filebeat cromerc-opensysusers-a12528f/test/gitlab-runner.conf000066400000000000000000000001021431471057600226560ustar00rootroot00000000000000u gitlab-runner 107 "GitLab Runner" /var/lib/gitlab-runner cromerc-opensysusers-a12528f/test/grafana.conf000066400000000000000000000000371431471057600215130ustar00rootroot00000000000000u grafana - - /var/lib/grafana cromerc-opensysusers-a12528f/test/hefur.conf000066400000000000000000000000341431471057600212220ustar00rootroot00000000000000u hefur - - /var/lib/hefurd cromerc-opensysusers-a12528f/test/jenkins.conf000066400000000000000000000000661431471057600215570ustar00rootroot00000000000000u jenkins - "Jenkins CI" /var/lib/jenkins g jenkins - cromerc-opensysusers-a12528f/test/lldpd.conf000066400000000000000000000001461431471057600212140ustar00rootroot00000000000000# https://wiki.archlinux.org/index.php/DeveloperWiki:UID_/_GID_Database u lldpd 127 - - m lldpd lldpd cromerc-opensysusers-a12528f/test/locate.conf000066400000000000000000000000201431471057600213530ustar00rootroot00000000000000g locate 21 - - cromerc-opensysusers-a12528f/test/mailman.conf000066400000000000000000000000711431471057600215300ustar00rootroot00000000000000u mailman 80 "GNU Mailing List Manager" /usr/lib/mailman cromerc-opensysusers-a12528f/test/mariadb.conf000066400000000000000000000000441431471057600215110ustar00rootroot00000000000000u mysql 89 "MariaDB" /var/lib/mysql cromerc-opensysusers-a12528f/test/minidlna.conf000066400000000000000000000000721431471057600217060ustar00rootroot00000000000000u minidlna - "minidlna server" /var/cache/minidlna cromerc-opensysusers-a12528f/test/mldonkey.conf000066400000000000000000000000661431471057600217400ustar00rootroot00000000000000u mldonkey - "Mldonkey daemon user" /var/lib/mldonkey cromerc-opensysusers-a12528f/test/mosquitto.conf000066400000000000000000000000611431471057600221550ustar00rootroot00000000000000u mosquitto - "Mosquitto MQTT Broker" /var/empty cromerc-opensysusers-a12528f/test/nbd.conf000066400000000000000000000000531431471057600206550ustar00rootroot00000000000000u nbd 44 "Network Block Device" /var/empty cromerc-opensysusers-a12528f/test/openldap.conf000066400000000000000000000000531431471057600217140ustar00rootroot00000000000000u ldap 439 "LDAP Server" /var/lib/openldap cromerc-opensysusers-a12528f/test/pesign.conf000066400000000000000000000000451431471057600214000ustar00rootroot00000000000000u pesign 312 "pesign signing daemon" cromerc-opensysusers-a12528f/test/privoxy.conf000066400000000000000000000000271431471057600216330ustar00rootroot00000000000000u privoxy 42 "Privoxy" cromerc-opensysusers-a12528f/test/qemu.conf000066400000000000000000000000131431471057600210550ustar00rootroot00000000000000g kvm 78 - cromerc-opensysusers-a12528f/test/quagga.conf000066400000000000000000000000311431471057600213530ustar00rootroot00000000000000u quagga - - /run/quagga cromerc-opensysusers-a12528f/test/rethinkdb.conf000066400000000000000000000000711431471057600220640ustar00rootroot00000000000000u rethinkdb - "Rethinkdb daemon user" /var/lib/rethinkdb cromerc-opensysusers-a12528f/test/rkt.conf000066400000000000000000000000321431471057600207070ustar00rootroot00000000000000g rkt - - g rkt-admin - - cromerc-opensysusers-a12528f/test/squid.conf000066400000000000000000000000301431471057600212320ustar00rootroot00000000000000u proxy 15 - /var/empty cromerc-opensysusers-a12528f/test/sslh.conf000066400000000000000000000000151431471057600210610ustar00rootroot00000000000000u sslh - - - cromerc-opensysusers-a12528f/test/synapse.conf000066400000000000000000000000651431471057600215770ustar00rootroot00000000000000u synapse 198 "Matrix Synapse user" /var/lib/synapse cromerc-opensysusers-a12528f/test/syncthing-relaysrv.conf000066400000000000000000000001071431471057600237650ustar00rootroot00000000000000u syncthing-relaysrv - "Syncthing relay server" g syncthing-relaysrv - cromerc-opensysusers-a12528f/test/tomcat7.conf000066400000000000000000000000601431471057600214660ustar00rootroot00000000000000u tomcat7 71 "Tomcat 7 user" /usr/share/tomcat7 cromerc-opensysusers-a12528f/test/tomcat8.conf000066400000000000000000000000601431471057600214670ustar00rootroot00000000000000u tomcat8 57 "Tomcat 8 user" /usr/share/tomcat8 cromerc-opensysusers-a12528f/test/transmission-cli.conf000066400000000000000000000001121431471057600234040ustar00rootroot00000000000000u transmission 169 "Transmission BitTorrent Daemon" /var/lib/transmission cromerc-opensysusers-a12528f/test/unifi.conf000066400000000000000000000000201431471057600212160ustar00rootroot00000000000000u unifi 113 - - cromerc-opensysusers-a12528f/test/util-linux.conf000066400000000000000000000000131431471057600222200ustar00rootroot00000000000000u uuidd 68 cromerc-opensysusers-a12528f/test/varnish.conf000066400000000000000000000000561431471057600215670ustar00rootroot00000000000000u varnish - "Varnish Cache Proxy" g varnish - cromerc-opensysusers-a12528f/test/virtualbox-guest-utils.conf000066400000000000000000000000171431471057600245740ustar00rootroot00000000000000g vboxsf 109 - cromerc-opensysusers-a12528f/test/virtualbox.conf000066400000000000000000000000221431471057600223050ustar00rootroot00000000000000g vboxusers 108 - cromerc-opensysusers-a12528f/test/zabbix-agent.conf000066400000000000000000000000531431471057600224650ustar00rootroot00000000000000u zabbix-agent 172 - /var/lib/zabbix-agent cromerc-opensysusers-a12528f/test/zabbix-proxy.conf000066400000000000000000000000531431471057600225500ustar00rootroot00000000000000u zabbix-proxy 171 - /var/lib/zabbix-proxy cromerc-opensysusers-a12528f/test/zabbix-server.conf000066400000000000000000000000551431471057600226770ustar00rootroot00000000000000u zabbix-server 170 - /var/lib/zabbix-server cromerc-opensysusers-a12528f/test/znc.conf000066400000000000000000000000271431471057600207050ustar00rootroot00000000000000u znc - - /var/lib/znc