shaba/systemd-stable
1
1
Fork 0
mirror of https://github.com/systemd/systemd-stable.git synced 2024-12-25 23:21:33 +03:00
Code
7cb791bcac
systemd-stable/sysusers.d/systemd.conf.in

24 lines
828 B
Plaintext
Raw Normal View History

sysusers: split up default sysusers snippet This ways, distributions have an easier way to replace the OS specific generic groups/users while keeping systemd's own.
2014-06-30 00:26:19 +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.
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 systemd-journal {{SYSTEMD_JOURNAL_GID}} -
meson: replace some m4 templates with jinja2 m4 was nice in '85, but the syntax feels a bit dated. Since we use python for meson, let's use a popular python templating engine to replace some m4 usage. A little nicety is that typos are caught: FAILED: sysusers.d/systemd-remote.conf /usr/bin/meson --internal exe --capture sysusers.d/systemd-remote.conf -- /home/zbyszek/src/systemd/tools/meson-render-jinja2.py config.h ../sysusers.d/systemd-remote.conf.j2 Traceback (most recent call last): File "/home/zbyszek/src/systemd/tools/meson-render-jinja2.py", line 28, in <module> print(render(sys.argv[2], defines)) File "/home/zbyszek/src/systemd/tools/meson-render-jinja2.py", line 24, in render return template.render(defines) File "/usr/lib/python3.9/site-packages/jinja2/environment.py", line 1090, in render self.environment.handle_exception() File "/usr/lib/python3.9/site-packages/jinja2/environment.py", line 832, in handle_exception reraise(*rewrite_traceback_stack(source=source)) File "/usr/lib/python3.9/site-packages/jinja2/_compat.py", line 28, in reraise raise value.with_traceback(tb) File "<template>", line 8, in top-level template code jinja2.exceptions.UndefinedError: 'HAVE_MICROHTTP' is undefined This checking mirrors what 349cc4a507c4d84fcadf61f42159ea6412717896 did for C defines.
2021-05-16 12:55:36 +03:00
{% if ENABLE_NETWORKD %}
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
u systemd-network {{SYSTEMD_NETWORK_UID}} "systemd Network Management"
meson: replace some m4 templates with jinja2 m4 was nice in '85, but the syntax feels a bit dated. Since we use python for meson, let's use a popular python templating engine to replace some m4 usage. A little nicety is that typos are caught: FAILED: sysusers.d/systemd-remote.conf /usr/bin/meson --internal exe --capture sysusers.d/systemd-remote.conf -- /home/zbyszek/src/systemd/tools/meson-render-jinja2.py config.h ../sysusers.d/systemd-remote.conf.j2 Traceback (most recent call last): File "/home/zbyszek/src/systemd/tools/meson-render-jinja2.py", line 28, in <module> print(render(sys.argv[2], defines)) File "/home/zbyszek/src/systemd/tools/meson-render-jinja2.py", line 24, in render return template.render(defines) File "/usr/lib/python3.9/site-packages/jinja2/environment.py", line 1090, in render self.environment.handle_exception() File "/usr/lib/python3.9/site-packages/jinja2/environment.py", line 832, in handle_exception reraise(*rewrite_traceback_stack(source=source)) File "/usr/lib/python3.9/site-packages/jinja2/_compat.py", line 28, in reraise raise value.with_traceback(tb) File "<template>", line 8, in top-level template code jinja2.exceptions.UndefinedError: 'HAVE_MICROHTTP' is undefined This checking mirrors what 349cc4a507c4d84fcadf61f42159ea6412717896 did for C defines.
2021-05-16 12:55:36 +03:00
{% endif %}
{% if ENABLE_OOMD %}
systemd-oomd: service files
2020-06-19 21:41:03 +03:00
u systemd-oom - "systemd Userspace OOM Killer"
meson: replace some m4 templates with jinja2 m4 was nice in '85, but the syntax feels a bit dated. Since we use python for meson, let's use a popular python templating engine to replace some m4 usage. A little nicety is that typos are caught: FAILED: sysusers.d/systemd-remote.conf /usr/bin/meson --internal exe --capture sysusers.d/systemd-remote.conf -- /home/zbyszek/src/systemd/tools/meson-render-jinja2.py config.h ../sysusers.d/systemd-remote.conf.j2 Traceback (most recent call last): File "/home/zbyszek/src/systemd/tools/meson-render-jinja2.py", line 28, in <module> print(render(sys.argv[2], defines)) File "/home/zbyszek/src/systemd/tools/meson-render-jinja2.py", line 24, in render return template.render(defines) File "/usr/lib/python3.9/site-packages/jinja2/environment.py", line 1090, in render self.environment.handle_exception() File "/usr/lib/python3.9/site-packages/jinja2/environment.py", line 832, in handle_exception reraise(*rewrite_traceback_stack(source=source)) File "/usr/lib/python3.9/site-packages/jinja2/_compat.py", line 28, in reraise raise value.with_traceback(tb) File "<template>", line 8, in top-level template code jinja2.exceptions.UndefinedError: 'HAVE_MICROHTTP' is undefined This checking mirrors what 349cc4a507c4d84fcadf61f42159ea6412717896 did for C defines.
2021-05-16 12:55:36 +03:00
{% endif %}
{% if ENABLE_RESOLVE %}
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
u systemd-resolve {{SYSTEMD_RESOLVE_UID}} "systemd Resolver"
meson: replace some m4 templates with jinja2 m4 was nice in '85, but the syntax feels a bit dated. Since we use python for meson, let's use a popular python templating engine to replace some m4 usage. A little nicety is that typos are caught: FAILED: sysusers.d/systemd-remote.conf /usr/bin/meson --internal exe --capture sysusers.d/systemd-remote.conf -- /home/zbyszek/src/systemd/tools/meson-render-jinja2.py config.h ../sysusers.d/systemd-remote.conf.j2 Traceback (most recent call last): File "/home/zbyszek/src/systemd/tools/meson-render-jinja2.py", line 28, in <module> print(render(sys.argv[2], defines)) File "/home/zbyszek/src/systemd/tools/meson-render-jinja2.py", line 24, in render return template.render(defines) File "/usr/lib/python3.9/site-packages/jinja2/environment.py", line 1090, in render self.environment.handle_exception() File "/usr/lib/python3.9/site-packages/jinja2/environment.py", line 832, in handle_exception reraise(*rewrite_traceback_stack(source=source)) File "/usr/lib/python3.9/site-packages/jinja2/_compat.py", line 28, in reraise raise value.with_traceback(tb) File "<template>", line 8, in top-level template code jinja2.exceptions.UndefinedError: 'HAVE_MICROHTTP' is undefined This checking mirrors what 349cc4a507c4d84fcadf61f42159ea6412717896 did for C defines.
2021-05-16 12:55:36 +03:00
{% endif %}
{% if ENABLE_TIMESYNCD %}
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
u systemd-timesync {{SYSTEMD_TIMESYNC_UID}} "systemd Time Synchronization"
meson: replace some m4 templates with jinja2 m4 was nice in '85, but the syntax feels a bit dated. Since we use python for meson, let's use a popular python templating engine to replace some m4 usage. A little nicety is that typos are caught: FAILED: sysusers.d/systemd-remote.conf /usr/bin/meson --internal exe --capture sysusers.d/systemd-remote.conf -- /home/zbyszek/src/systemd/tools/meson-render-jinja2.py config.h ../sysusers.d/systemd-remote.conf.j2 Traceback (most recent call last): File "/home/zbyszek/src/systemd/tools/meson-render-jinja2.py", line 28, in <module> print(render(sys.argv[2], defines)) File "/home/zbyszek/src/systemd/tools/meson-render-jinja2.py", line 24, in render return template.render(defines) File "/usr/lib/python3.9/site-packages/jinja2/environment.py", line 1090, in render self.environment.handle_exception() File "/usr/lib/python3.9/site-packages/jinja2/environment.py", line 832, in handle_exception reraise(*rewrite_traceback_stack(source=source)) File "/usr/lib/python3.9/site-packages/jinja2/_compat.py", line 28, in reraise raise value.with_traceback(tb) File "<template>", line 8, in top-level template code jinja2.exceptions.UndefinedError: 'HAVE_MICROHTTP' is undefined This checking mirrors what 349cc4a507c4d84fcadf61f42159ea6412717896 did for C defines.
2021-05-16 12:55:36 +03:00
{% endif %}
{% if ENABLE_COREDUMP %}
coredump: dump priviliges when processing system coredumps Let's add an extra-safety net and change UID/GID to the "systemd-coredump" user when processing coredumps from system user. For coredumps of normal users we keep the current logic of processing the coredumps from the user id the coredump was created under. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=87354
2016-02-09 01:35:24 +03:00
u systemd-coredump - "systemd Core Dumper"
meson: replace some m4 templates with jinja2 m4 was nice in '85, but the syntax feels a bit dated. Since we use python for meson, let's use a popular python templating engine to replace some m4 usage. A little nicety is that typos are caught: FAILED: sysusers.d/systemd-remote.conf /usr/bin/meson --internal exe --capture sysusers.d/systemd-remote.conf -- /home/zbyszek/src/systemd/tools/meson-render-jinja2.py config.h ../sysusers.d/systemd-remote.conf.j2 Traceback (most recent call last): File "/home/zbyszek/src/systemd/tools/meson-render-jinja2.py", line 28, in <module> print(render(sys.argv[2], defines)) File "/home/zbyszek/src/systemd/tools/meson-render-jinja2.py", line 24, in render return template.render(defines) File "/usr/lib/python3.9/site-packages/jinja2/environment.py", line 1090, in render self.environment.handle_exception() File "/usr/lib/python3.9/site-packages/jinja2/environment.py", line 832, in handle_exception reraise(*rewrite_traceback_stack(source=source)) File "/usr/lib/python3.9/site-packages/jinja2/_compat.py", line 28, in reraise raise value.with_traceback(tb) File "<template>", line 8, in top-level template code jinja2.exceptions.UndefinedError: 'HAVE_MICROHTTP' is undefined This checking mirrors what 349cc4a507c4d84fcadf61f42159ea6412717896 did for C defines.
2021-05-16 12:55:36 +03:00
{% endif %}
Copy Permalink