IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Let's make it slightly more likely that a per-user service manager is
killed than any system service. We use a conservative 100 (from a range
that goes all the way to 1000).
Replaces: #17426
Together with the previous commit this means: system manager and system
services are placed at OOM score adjustment 0 (specifically: they
inherit kernel default of 0). User service manager (both for root and
non-root) are placed at 100. User services for non-root are placed at
200, those for root inherit 100.
Note that processes forked off the user *sessions* (i.e. not forked off
the per-user service manager) remain at 0 (e.g. the shell process
created by a tty or ssh login). This probably should be
addressed too one day (maybe in pam_systemd?), but is not covered here.
Let's make our service managers slightly less likely to be killed by the
OOM killer by adjusting our services' OOM score adjustment to 100 above
ours. Do this conservatively, i.e. only for regular user sessions.
All other examples were relicensed to CC0-1.0 since they are intended
to be copied and pasted anywhere without any restrictions.
Relicense the last one too.
Documentation is licensed under LGPL-2.1-or-later.
Scripts are MIT to facilitate reuse.
Examples are relicensed to CC0-1.0 to maximise copy-and-paste
for users, with permission from authors.
It makes it easier to process the license automatically like other files.
The text of the license in tools/chromiumos/LICENSE matches
https://spdx.org/licenses/BSD-3-Clause.html exactly.
This is just a stupid file list, but without the header the file shows
up on the list of files without a header. I checked that 'systemd-update-po'
still works, so I think it's OK to add this.
The second call to name_to_handle_at_loop() didn't check for the specific
errors that can happen when the parent dir is mounted by nfs and instead of
falling back like it's done for the child dir, fd_is_mount_point() failed in
this case.
megasearch.net was meant to be a non-existing bogus domain, and had been
for a long time. But it seems some domain grabber recently registered
it, and it's an actual thing now:
$ host megasearch.net
megasearch.net has address 207.148.248.143
This causes the test to fail randomly.
Use search.example.com instead which yields
$ host search.example.com
Host search.example.com not found: 3(NXDOMAIN)
Fixes: #18357
Since f833df3 we now actually use the seccomp rules defined in portable
profiles. However, the default one is too restrictive for sanitizers, as
it blocks certain syscall required by LSan. Mitigate this by using the
'trusted' profile when running TEST-29-PORTABLE under sanitizers.
This adds a high level test verifying that syscall filtering in
combination with a simple architecture filter for the "native"
architecture works fine.
The commit 6597686865 ("seccomp: don't install filters for archs that
can't use syscalls") introduced a regression where filters may not be
installed for the "native" architecture. This means that setting
SystemCallArchitectures=native for a unit effectively disables the
SystemCallFilter= and SystemCallLog= options.
Conceptually, we have two filter stages:
1. architecture used for syscall (SystemCallArchitectures=)
2. syscall + architecture combination (SystemCallFilter=)
The above commit tried to optimize the filter generation by skipping the
second level filtering when it is not required.
However, systemd will never fully block the "native" architecture using
the first level filter. This makes the code a lot simpler, as systemd
can execve() the target binary using its own architecture. And, it
should be perfectly fine as the "native" architecture will always be the
one with the most restrictive seccomp filtering.
Said differently, the bug arises because (on x86_64):
1. x86_64 is permitted by libseccomp already
2. native != x86_64
3. the loop wants to block x86_64 because the permitted set only
contains "native" (i.e. "native" != "x86_64")
4. x86_64 is marked as blocked in seccomp_local_archs
Thereby we have an inconsistency, where it is marked as blocked in the
seccomp_local_archs array but it is allowed by libseccomp. i.e. we will
skip generating filter stage 2 without having stage 1 in place.
The fix is simple, we just skip the native architecture when looping
seccomp_local_archs. This way the inconsistency cannot happen.
systemd-udevd.service listens to kernel uevents and is needed for device
units to be available.
systemd-udevd.service is misspelled as systemd-udev.service in a couple places.
Fixing typo.
