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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Verify that service exited correctly if valid ports are passed to
SocketBind{Allow|Deny}=
Use `ncat` program starting a listening service binding to a specified
port, e.g.
"timeout --preserve-status -sSIGTERM 1s /bin/nc -l -p ${port} -vv"
Add supported and install unit interface for socket-bind feature.
supported verifies that
- unified cgroup hierarchy (cgroup v2) is used
- BPF_FRAMEWORK (libbpf + clang + llvm + bpftool) was available in
compile time
- kernel supports BPF_PROG_TYPE_CGROUP_SOCK_ADDR
- bpf programs can be loaded into kernel
- bpf link can be used
install:
- load bpf_object from bpf skeleton
- resize rules map to fit socket_bind_allow and socket_bind deny rules
from cgroup context
- populate cgroup-bpf maps with rules
- get bpf programs from bpf skeleton
- attach programs to unit cgroup using bpf link
- save bpf link in the unit
* Add `bpf-framework` feature gate with 'auto', 'true' and 'false' choices
* Add libbpf [0] dependency
* Search for clang llvm-strip and bpftool binaries in compile time to
generate bpf skeleton.
For libbpf [0], make 0.2.0 [1] the minimum required version.
If libbpf is satisfied, set HAVE_LIBBPF config option to 1.
If `bpf-framework` feature gate is set to 'auto', means that whether
bpf feature is enabled or now is defined by the presence of all of
libbpf, clang, llvm and bpftool in build
environment.
With 'auto' all dependencies are optional.
If the gate is set to `true`, make all of the libbpf, clang and llvm
dependencies mandatory.
If it's set to `false`, set `BPF_FRAMEWORK` to false and make libbpf
dependency optional.
libbpf dependency is dynamic followed by the common pattern in systemd.
meson, bpf: add build rule for socket_bind program
Add a build script to compile bpf source code. A program in restricted
C is compiled into an object file. Object file is converted to BPF
skeleton [0] header file.
If build with custom meson build rule, the target header will reside in
build/ directory (not in source tree), e.g the path for socket_bind:
`build/src/core/bpf/socket_bind/socket-bind.skel.h`
Script runs the phases:
* clang to generate *.o from restricted C
* llvm-strip to remove useless DWARF info
* bpf skeleton generation with bpftool
These phases are logged to stderr for debug purposes.
To include BTF debug information, -g option is passed to clang.
[0] https://lwn.net/Articles/806911/
Introduce BPF program compiled from BPF source code in
restricted C - socket-bind.
It addresses feature request [0].
The goal is to allow systemd services to bind(2) only to a predefined set
of ports. This prevents assigning socket address with unallowed port
to a socket and creating servers listening on that port.
This compliments firewalling feature presenting in systemd:
whereas cgroup/{egress|ingress} hooks act on packets, this doesn't
protect from untrusted service or payload hijacking an important port.
While ports in 0-1023 range are restricted to root only, 1024-65535
range is not protected by any mean.
Performance is another aspect of socket_bind feature since per-packet
cost can be eliminated for some port-based filtering policies.
The feature is implemented with cgroup/bind{4|6} hooks [1].
In contrast to the present systemd approach using raw bpf instructions,
this program is compiled from sources. Stretch goal is to
make bpf ecosystem in systemd more friendly for developer and to clear
path for more BPF programs.
[0] https://github.com/systemd/systemd/pull/13496#issuecomment-570573085
[1] https://www.spinics.net/lists/netdev/msg489054.html
Specifying the test number manually is tedious and prone to errors (as
recently proven). Since we have all the necessary data to work out the
test number, let's do it automagically.
We should test both serialization and deserialization works properly.
But the serialization/deserialization code is deeply entwined with the
manager state, and I think quite a bit of refactoring will be required before
this is possible. But let's at least add this simple test for now.
After 4b30f2e135ee84041bb597edca7225858f4ef4fb, reading stable_secret
sysctl property fails with -ENOMEM, instead of -EIO.
This is due to read_full_virtual_file() uses read() as the backend while
read_one_line_file() uses fgetc(). And each functions return different
error on fails.
Anyway, the failure is harmless here. So, the log message and comment is
updated.
Closes one of the issues in #19410.
Previously, we'd generally attempt the operation first, without any
passwords, and only query for a password if that operation then fails
and asks for one. This is done to improve compatibility with
password-less authentication schemes, such as security tokens and
similar.
This patch modifies this slightly: if a password can be acquired cheaply
via the keyring password cache, the $CREDENTIALS_PATH credential store,
or the $PASSWORD/$PIN environment variables, acquire it *before* issuing
the first requested.
This should save us a pointless roundtrip, and should never hurt.
We want to use the result in a shell pipeline hence use -P mode (pipe
mode) instead of -t mode (interactive tty mode) for systemd-run.
This shouldn't change much about the test, but is slightly more correct
(and quicker).
We have to invoke the tests as superuser, and not being able to read
the journal as the invoking user is annoying. I don't think there are
any security considerations here, since the invoking user can already
put arbitrary code in the Makefile and test scripts which get executed
with root privileges.
Let's enable this in all tools that intend to write to the OS images.
It's not conditionalized for now, as there already is conditionalization
in the existance or absence of the flag in the GPT partition table (and
it's opt-in), hence it should be OK to just enable this by default for
now if the flag is set.
systemd-repart can grow partitions dynamically at boot, but it won't
grow the file systems inside them. In /etc/fstab you can request that
via x-systemd.growfs. So far we didn't have a nice scheme for images
with GPT auto-discovery however, and that meant in particular in tools
such as systemd-nspawn the file systems couldn't be grown automatically.
Let's address this: let's define a new GPT partition flag that can be
set for our partition types. If set it indicates that the file system
should be grown to the partition size on mount.
This commit adds the flag and adds code to discover it when dissecting
images. There's no code yet to actually do something about it.
Let's rename MountpointsFlags → MountPointFlags. In most of our codebase
we name things mount_point/MountPoint rather than mountpoint/Mountpoint,
do so here too.
Also, prefix the enum values with "MOUNT_". The fact the enum values
weren#t prefixed was pretty unique in our codebase, and pretty
surprising. Let's fix that.
This is just refactoring, no actual change in behaviour
