1
0
mirror of https://github.com/systemd/systemd.git synced 2024-12-25 01:34:28 +03:00
systemd/sysusers.d/basic.conf.in

41 lines
1.5 KiB
Plaintext
Raw Normal View History

sysusers: add minimal tool to reconstruct /etc/passwd and /etc/group from static files systemd-sysusers is a tool to reconstruct /etc/passwd and /etc/group from static definition files that take a lot of inspiration from tmpfiles snippets. These snippets should carry information about system users only. To make sure it is not misused for normal users these snippets only allow configuring UID and gecos field for each user, but do not allow configuration of the home directory or shell, which is necessary for real login users. The purpose of this tool is to enable state-less systems that can populate /etc with the minimal files necessary, solely from static data in /usr. systemd-sysuser is additive only, and will never override existing users. This tool will create these files directly, and not via some user database abtsraction layer. This is appropriate as this tool is supposed to run really early at boot, and is only useful for creating system users, and system users cannot be stored in remote databases anyway. The tool is also useful to be invoked from RPM scriptlets, instead of useradd. This allows moving from imperative user descriptions in RPM to declarative descriptions. The UID/GID for a user/group to be created can either be chosen dynamic, or fixed, or be read from the owner of a file in the file system, in order to support reconstructing the correct IDs for files that shall be owned by them. This also adds a minimal user definition file, that should be sufficient for most basic systems. Distributions are expected to patch these files and augment the contents, for example with fixed UIDs for the users where that's necessary.
2014-06-13 00:54:02 +04:00
# 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:0 "Super User" /root
sysusers: add minimal tool to reconstruct /etc/passwd and /etc/group from static files systemd-sysusers is a tool to reconstruct /etc/passwd and /etc/group from static definition files that take a lot of inspiration from tmpfiles snippets. These snippets should carry information about system users only. To make sure it is not misused for normal users these snippets only allow configuring UID and gecos field for each user, but do not allow configuration of the home directory or shell, which is necessary for real login users. The purpose of this tool is to enable state-less systems that can populate /etc with the minimal files necessary, solely from static data in /usr. systemd-sysuser is additive only, and will never override existing users. This tool will create these files directly, and not via some user database abtsraction layer. This is appropriate as this tool is supposed to run really early at boot, and is only useful for creating system users, and system users cannot be stored in remote databases anyway. The tool is also useful to be invoked from RPM scriptlets, instead of useradd. This allows moving from imperative user descriptions in RPM to declarative descriptions. The UID/GID for a user/group to be created can either be chosen dynamic, or fixed, or be read from the owner of a file in the file system, in order to support reconstructing the correct IDs for files that shall be owned by them. This also adds a minimal user definition file, that should be sufficient for most basic systems. Distributions are expected to patch these files and augment the contents, for example with fixed UIDs for the users where that's necessary.
2014-06-13 00:54:02 +04:00
# The nobody user/group for NFS file systems
g {{NOBODY_GROUP_NAME}} 65534 - -
u {{NOBODY_USER_NAME }} 65534:65534 "Kernel Overflow User" -
sysusers: add minimal tool to reconstruct /etc/passwd and /etc/group from static files systemd-sysusers is a tool to reconstruct /etc/passwd and /etc/group from static definition files that take a lot of inspiration from tmpfiles snippets. These snippets should carry information about system users only. To make sure it is not misused for normal users these snippets only allow configuring UID and gecos field for each user, but do not allow configuration of the home directory or shell, which is necessary for real login users. The purpose of this tool is to enable state-less systems that can populate /etc with the minimal files necessary, solely from static data in /usr. systemd-sysuser is additive only, and will never override existing users. This tool will create these files directly, and not via some user database abtsraction layer. This is appropriate as this tool is supposed to run really early at boot, and is only useful for creating system users, and system users cannot be stored in remote databases anyway. The tool is also useful to be invoked from RPM scriptlets, instead of useradd. This allows moving from imperative user descriptions in RPM to declarative descriptions. The UID/GID for a user/group to be created can either be chosen dynamic, or fixed, or be read from the owner of a file in the file system, in order to support reconstructing the correct IDs for files that shall be owned by them. This also adds a minimal user definition file, that should be sufficient for most basic systems. Distributions are expected to patch these files and augment the contents, for example with fixed UIDs for the users where that's necessary.
2014-06-13 00:54:02 +04:00
# Administrator group: can *see* more than normal users
meson: allow "soft-static" allocations for uids and gids in the initrd The general idea with users and groups created through sysusers is that an appropriate number is picked when the allocation is made. The number that is selected will be different on each system based on the order of creation of users, installed packages, etc. Since system users and groups are not shared between installations, this generally is not an issue. But it becomes a problem for initrd: some file systems are shared between the initrd and the host (/run and /dev are probably the only ones that matter). If the allocations are different in the host and the initrd, and files survive switch-root, they will have wrong ownership. This makes the gids build-time-configurable for all groups and users where state may survive the switch from initrd to the host. In particular, all "hardware access" groups are like this: files in /dev will be owned by them. Eventually the new udev would change ownership, but there would be a momemnt where the files were owned by the wrong group. The allocations are "soft-static" in the language of Fedora packaging guidelines: the uid/gid will be used if possible, but we'll fall back to a different one. TTY_GID is the exception, because the number is used directly. Similarly, the possibility to configure "soft-static" uids is added for daemons which may usefully run in the initramfs: systemd-network (lease information and interface state is serialized to /run), systemd-resolve (stub files and interface state), systemd-timesync (/run/systemd/timesync). Journal files are owned by the group systemd-journal, and acls are granted for wheel and adm. systemd-oom and systemd-coredump are excluded from this patch: I assume that oomd is not useful in the initrd, and coredump leaves no state (it only creates a pipe in /run?). The defaults are not changed: if nothing is configured, dynamic allocation will be used. I looked at a Debian system, and the numbers are all different than on Fedora. For Fedora, see the list of uids and gids at https://pagure.io/setup/blob/master/f/uidgid. In particular, systemd-network and systemd-resolve got soft-static numbers to make it easy to transition from a non-host-specific initrd to a host system already a few years back (https://bugzilla.redhat.com/show_bug.cgi?id=1102002). I also requested static allocations for sgx, input, render in https://pagure.io/packaging-committee/issue/1078, https://pagure.io/setup/pull-request/27.
2021-05-23 23:00:22 +03:00
g adm {{ADM_GID }} - -
sysusers: add minimal tool to reconstruct /etc/passwd and /etc/group from static files systemd-sysusers is a tool to reconstruct /etc/passwd and /etc/group from static definition files that take a lot of inspiration from tmpfiles snippets. These snippets should carry information about system users only. To make sure it is not misused for normal users these snippets only allow configuring UID and gecos field for each user, but do not allow configuration of the home directory or shell, which is necessary for real login users. The purpose of this tool is to enable state-less systems that can populate /etc with the minimal files necessary, solely from static data in /usr. systemd-sysuser is additive only, and will never override existing users. This tool will create these files directly, and not via some user database abtsraction layer. This is appropriate as this tool is supposed to run really early at boot, and is only useful for creating system users, and system users cannot be stored in remote databases anyway. The tool is also useful to be invoked from RPM scriptlets, instead of useradd. This allows moving from imperative user descriptions in RPM to declarative descriptions. The UID/GID for a user/group to be created can either be chosen dynamic, or fixed, or be read from the owner of a file in the file system, in order to support reconstructing the correct IDs for files that shall be owned by them. This also adds a minimal user definition file, that should be sufficient for most basic systems. Distributions are expected to patch these files and augment the contents, for example with fixed UIDs for the users where that's necessary.
2014-06-13 00:54:02 +04:00
# Administrator group: can *do* more than normal users
meson: allow "soft-static" allocations for uids and gids in the initrd The general idea with users and groups created through sysusers is that an appropriate number is picked when the allocation is made. The number that is selected will be different on each system based on the order of creation of users, installed packages, etc. Since system users and groups are not shared between installations, this generally is not an issue. But it becomes a problem for initrd: some file systems are shared between the initrd and the host (/run and /dev are probably the only ones that matter). If the allocations are different in the host and the initrd, and files survive switch-root, they will have wrong ownership. This makes the gids build-time-configurable for all groups and users where state may survive the switch from initrd to the host. In particular, all "hardware access" groups are like this: files in /dev will be owned by them. Eventually the new udev would change ownership, but there would be a momemnt where the files were owned by the wrong group. The allocations are "soft-static" in the language of Fedora packaging guidelines: the uid/gid will be used if possible, but we'll fall back to a different one. TTY_GID is the exception, because the number is used directly. Similarly, the possibility to configure "soft-static" uids is added for daemons which may usefully run in the initramfs: systemd-network (lease information and interface state is serialized to /run), systemd-resolve (stub files and interface state), systemd-timesync (/run/systemd/timesync). Journal files are owned by the group systemd-journal, and acls are granted for wheel and adm. systemd-oom and systemd-coredump are excluded from this patch: I assume that oomd is not useful in the initrd, and coredump leaves no state (it only creates a pipe in /run?). The defaults are not changed: if nothing is configured, dynamic allocation will be used. I looked at a Debian system, and the numbers are all different than on Fedora. For Fedora, see the list of uids and gids at https://pagure.io/setup/blob/master/f/uidgid. In particular, systemd-network and systemd-resolve got soft-static numbers to make it easy to transition from a non-host-specific initrd to a host system already a few years back (https://bugzilla.redhat.com/show_bug.cgi?id=1102002). I also requested static allocations for sgx, input, render in https://pagure.io/packaging-committee/issue/1078, https://pagure.io/setup/pull-request/27.
2021-05-23 23:00:22 +03:00
g wheel {{WHEEL_GID }} - -
sysusers: add minimal tool to reconstruct /etc/passwd and /etc/group from static files systemd-sysusers is a tool to reconstruct /etc/passwd and /etc/group from static definition files that take a lot of inspiration from tmpfiles snippets. These snippets should carry information about system users only. To make sure it is not misused for normal users these snippets only allow configuring UID and gecos field for each user, but do not allow configuration of the home directory or shell, which is necessary for real login users. The purpose of this tool is to enable state-less systems that can populate /etc with the minimal files necessary, solely from static data in /usr. systemd-sysuser is additive only, and will never override existing users. This tool will create these files directly, and not via some user database abtsraction layer. This is appropriate as this tool is supposed to run really early at boot, and is only useful for creating system users, and system users cannot be stored in remote databases anyway. The tool is also useful to be invoked from RPM scriptlets, instead of useradd. This allows moving from imperative user descriptions in RPM to declarative descriptions. The UID/GID for a user/group to be created can either be chosen dynamic, or fixed, or be read from the owner of a file in the file system, in order to support reconstructing the correct IDs for files that shall be owned by them. This also adds a minimal user definition file, that should be sufficient for most basic systems. Distributions are expected to patch these files and augment the contents, for example with fixed UIDs for the users where that's necessary.
2014-06-13 00:54:02 +04:00
meson: allow "soft-static" allocations for uids and gids in the initrd The general idea with users and groups created through sysusers is that an appropriate number is picked when the allocation is made. The number that is selected will be different on each system based on the order of creation of users, installed packages, etc. Since system users and groups are not shared between installations, this generally is not an issue. But it becomes a problem for initrd: some file systems are shared between the initrd and the host (/run and /dev are probably the only ones that matter). If the allocations are different in the host and the initrd, and files survive switch-root, they will have wrong ownership. This makes the gids build-time-configurable for all groups and users where state may survive the switch from initrd to the host. In particular, all "hardware access" groups are like this: files in /dev will be owned by them. Eventually the new udev would change ownership, but there would be a momemnt where the files were owned by the wrong group. The allocations are "soft-static" in the language of Fedora packaging guidelines: the uid/gid will be used if possible, but we'll fall back to a different one. TTY_GID is the exception, because the number is used directly. Similarly, the possibility to configure "soft-static" uids is added for daemons which may usefully run in the initramfs: systemd-network (lease information and interface state is serialized to /run), systemd-resolve (stub files and interface state), systemd-timesync (/run/systemd/timesync). Journal files are owned by the group systemd-journal, and acls are granted for wheel and adm. systemd-oom and systemd-coredump are excluded from this patch: I assume that oomd is not useful in the initrd, and coredump leaves no state (it only creates a pipe in /run?). The defaults are not changed: if nothing is configured, dynamic allocation will be used. I looked at a Debian system, and the numbers are all different than on Fedora. For Fedora, see the list of uids and gids at https://pagure.io/setup/blob/master/f/uidgid. In particular, systemd-network and systemd-resolve got soft-static numbers to make it easy to transition from a non-host-specific initrd to a host system already a few years back (https://bugzilla.redhat.com/show_bug.cgi?id=1102002). I also requested static allocations for sgx, input, render in https://pagure.io/packaging-committee/issue/1078, https://pagure.io/setup/pull-request/27.
2021-05-23 23:00:22 +03:00
# Access to shared database of users on the system
g utmp {{UTMP_GID }} - -
sysusers: add minimal tool to reconstruct /etc/passwd and /etc/group from static files systemd-sysusers is a tool to reconstruct /etc/passwd and /etc/group from static definition files that take a lot of inspiration from tmpfiles snippets. These snippets should carry information about system users only. To make sure it is not misused for normal users these snippets only allow configuring UID and gecos field for each user, but do not allow configuration of the home directory or shell, which is necessary for real login users. The purpose of this tool is to enable state-less systems that can populate /etc with the minimal files necessary, solely from static data in /usr. systemd-sysuser is additive only, and will never override existing users. This tool will create these files directly, and not via some user database abtsraction layer. This is appropriate as this tool is supposed to run really early at boot, and is only useful for creating system users, and system users cannot be stored in remote databases anyway. The tool is also useful to be invoked from RPM scriptlets, instead of useradd. This allows moving from imperative user descriptions in RPM to declarative descriptions. The UID/GID for a user/group to be created can either be chosen dynamic, or fixed, or be read from the owner of a file in the file system, in order to support reconstructing the correct IDs for files that shall be owned by them. This also adds a minimal user definition file, that should be sufficient for most basic systems. Distributions are expected to patch these files and augment the contents, for example with fixed UIDs for the users where that's necessary.
2014-06-13 00:54:02 +04:00
meson: allow "soft-static" allocations for uids and gids in the initrd The general idea with users and groups created through sysusers is that an appropriate number is picked when the allocation is made. The number that is selected will be different on each system based on the order of creation of users, installed packages, etc. Since system users and groups are not shared between installations, this generally is not an issue. But it becomes a problem for initrd: some file systems are shared between the initrd and the host (/run and /dev are probably the only ones that matter). If the allocations are different in the host and the initrd, and files survive switch-root, they will have wrong ownership. This makes the gids build-time-configurable for all groups and users where state may survive the switch from initrd to the host. In particular, all "hardware access" groups are like this: files in /dev will be owned by them. Eventually the new udev would change ownership, but there would be a momemnt where the files were owned by the wrong group. The allocations are "soft-static" in the language of Fedora packaging guidelines: the uid/gid will be used if possible, but we'll fall back to a different one. TTY_GID is the exception, because the number is used directly. Similarly, the possibility to configure "soft-static" uids is added for daemons which may usefully run in the initramfs: systemd-network (lease information and interface state is serialized to /run), systemd-resolve (stub files and interface state), systemd-timesync (/run/systemd/timesync). Journal files are owned by the group systemd-journal, and acls are granted for wheel and adm. systemd-oom and systemd-coredump are excluded from this patch: I assume that oomd is not useful in the initrd, and coredump leaves no state (it only creates a pipe in /run?). The defaults are not changed: if nothing is configured, dynamic allocation will be used. I looked at a Debian system, and the numbers are all different than on Fedora. For Fedora, see the list of uids and gids at https://pagure.io/setup/blob/master/f/uidgid. In particular, systemd-network and systemd-resolve got soft-static numbers to make it easy to transition from a non-host-specific initrd to a host system already a few years back (https://bugzilla.redhat.com/show_bug.cgi?id=1102002). I also requested static allocations for sgx, input, render in https://pagure.io/packaging-committee/issue/1078, https://pagure.io/setup/pull-request/27.
2021-05-23 23:00:22 +03:00
# Physical and virtual hardware access groups
g audio {{AUDIO_GID }} - -
g cdrom {{CDROM_GID }} - -
g dialout {{DIALOUT_GID}} - -
g disk {{DISK_GID }} - -
g input {{INPUT_GID }} - -
g kmem {{KMEM_GID }} - -
g kvm {{KVM_GID }} - -
g lp {{LP_GID }} - -
g render {{RENDER_GID }} - -
g sgx {{SGX_GID }} - -
g tape {{TAPE_GID }} - -
g tty {{TTY_GID }} - -
g video {{VIDEO_GID }} - -
sysusers: add minimal tool to reconstruct /etc/passwd and /etc/group from static files systemd-sysusers is a tool to reconstruct /etc/passwd and /etc/group from static definition files that take a lot of inspiration from tmpfiles snippets. These snippets should carry information about system users only. To make sure it is not misused for normal users these snippets only allow configuring UID and gecos field for each user, but do not allow configuration of the home directory or shell, which is necessary for real login users. The purpose of this tool is to enable state-less systems that can populate /etc with the minimal files necessary, solely from static data in /usr. systemd-sysuser is additive only, and will never override existing users. This tool will create these files directly, and not via some user database abtsraction layer. This is appropriate as this tool is supposed to run really early at boot, and is only useful for creating system users, and system users cannot be stored in remote databases anyway. The tool is also useful to be invoked from RPM scriptlets, instead of useradd. This allows moving from imperative user descriptions in RPM to declarative descriptions. The UID/GID for a user/group to be created can either be chosen dynamic, or fixed, or be read from the owner of a file in the file system, in order to support reconstructing the correct IDs for files that shall be owned by them. This also adds a minimal user definition file, that should be sufficient for most basic systems. Distributions are expected to patch these files and augment the contents, for example with fixed UIDs for the users where that's necessary.
2014-06-13 00:54:02 +04:00
# Default group for normal users
meson: allow "soft-static" allocations for uids and gids in the initrd The general idea with users and groups created through sysusers is that an appropriate number is picked when the allocation is made. The number that is selected will be different on each system based on the order of creation of users, installed packages, etc. Since system users and groups are not shared between installations, this generally is not an issue. But it becomes a problem for initrd: some file systems are shared between the initrd and the host (/run and /dev are probably the only ones that matter). If the allocations are different in the host and the initrd, and files survive switch-root, they will have wrong ownership. This makes the gids build-time-configurable for all groups and users where state may survive the switch from initrd to the host. In particular, all "hardware access" groups are like this: files in /dev will be owned by them. Eventually the new udev would change ownership, but there would be a momemnt where the files were owned by the wrong group. The allocations are "soft-static" in the language of Fedora packaging guidelines: the uid/gid will be used if possible, but we'll fall back to a different one. TTY_GID is the exception, because the number is used directly. Similarly, the possibility to configure "soft-static" uids is added for daemons which may usefully run in the initramfs: systemd-network (lease information and interface state is serialized to /run), systemd-resolve (stub files and interface state), systemd-timesync (/run/systemd/timesync). Journal files are owned by the group systemd-journal, and acls are granted for wheel and adm. systemd-oom and systemd-coredump are excluded from this patch: I assume that oomd is not useful in the initrd, and coredump leaves no state (it only creates a pipe in /run?). The defaults are not changed: if nothing is configured, dynamic allocation will be used. I looked at a Debian system, and the numbers are all different than on Fedora. For Fedora, see the list of uids and gids at https://pagure.io/setup/blob/master/f/uidgid. In particular, systemd-network and systemd-resolve got soft-static numbers to make it easy to transition from a non-host-specific initrd to a host system already a few years back (https://bugzilla.redhat.com/show_bug.cgi?id=1102002). I also requested static allocations for sgx, input, render in https://pagure.io/packaging-committee/issue/1078, https://pagure.io/setup/pull-request/27.
2021-05-23 23:00:22 +03:00
g users {{USERS_GID }} - -