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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
- Handle BPFProgram= property in string format
"<bpf_attach_type>:<bpffs_path>", e.g. egress:/sys/fs/bpf/egress-hook.
- Add dbus getter to list foreign bpf programs attached to a cgroup.
- Pin trivial bpf programs to bpf filesystem, compose BPFProgram= option
string and pass it to a unit. Programs store `0` in r0 BPF register for
denying action, e.g. drop a packet.
- Load trivial BPF programs
- Test is skipped if not run under root or if can not lock enough
memory.
- For egress and ingress hooks, test BPFProgram= option along with
with IP{Egress|Ingress}FilterPath=, expected result should not depend on
which rule is executed first.
Expected results for BPF_CGROUP_INET_INGRESS:
5 packets transmitted, 0 received, 100% packet loss, time 89ms
For BPF_CGROUP_INET_SOCK_CREATE:
ping: socket: Operation not permitted
- Introduce support of cgroup-bpf programs managed (i.e. compiled,
loaded to and unloaded from kernel) externally. Systemd is only
responsible for attaching programs to unit cgroup hence the name
'foreign'.
Foreign BPF programs are identified by bpf program ID and attach type.
systemd:
- Gets kernel FD of BPF program;
- Makes a unique identifier of BPF program from BPF attach type and
program ID. Same program IDs mean the same program, i.e the same
chunk of kernel memory. Even if the same program is passed multiple
times, identical (program_id, attach_type) instances are collapsed
into one;
- Attaches programs to unit cgroup.
- Store foreign bpf programs in cgroup context. A program is considered
foreign if it was loaded to a kernel by an entity external to systemd,
so systemd is responsible only for attach and detach paths.
- Support the case of pinned bpf programs: pinning to bpffs so a program
is kept loaded to the kernel even when program fd is closed by a user
application is a common way to extend program's lifetime.
- Aadd linked list node struct with attach type and bpffs path
fields.
Introduce bpf_cgroup_attach_type_table with accustomed attached type
names also used in bpftool.
Add bpf_cgroup_attach_type_{from|to}_string helpers to convert from|to
string representation of pinned bpf program, e.g.
"egress:/sys/fs/bpf/egress-hook" for
/sys/fs/bpf/egress-hook path and BPF_CGROUP_INET_EGRESS attach type.
Add helpers to:
- Create new BPFProgram instance from a path in bpf
filesystem and bpf attach type;
- Pin a program to bpf fs;
- Get BPF program ID by BPF program FD.
Reduced version of [0].
Use BPF_F_ALLOW_MULTI attach flag for bpf-firewall if kernel supports
it.
Aside from addressing security issue in [0] attaching with 'multi'
allows further attaching of cgroup egress, ingress hooks specified by
BPFProgram=.
[0] 4e42210d40
lstat() returns the error in errno, not as return value. Let's propagate
this correctly.
This broke the bolt test suite, as @gicmo discovered.
Follow-up for acfc2a1d15.
Let's define both an enum and a typedef named SpecialGlyph, the way we
usually do it.
Also, introduce an "invalid" special glyph, assigned to -EINVAL, also
like we always do it. (And handle it somewhat sanely in special_glyph()
'! grep -v' does *not* test that there are no matching lines.
Instead, it checks that whether there are any non-matching lines.
And of course, for the test to fail, '! grep' cannot be part of
an expression with &&.
We were grepping for 'hello world', and in the namespace we would
match on 'hello world', and outside, on 'echo "hello world"'. When
the condition check was fixed, the test gave a false positive.
We were invoking 'systemd-run bash', but the test invoked by bash
was not effective. When the result of that check is propagated, the
outer command fails.
create_fifo() was added in a2fc2f8dd3, and
would always ignore failure. The test was trying to fail in this case, but
we actually don't fail, which seems to be correct. We didn't notice before
because the test was ineffective.
To make things consistent, generally log at warning level, but don't propagate
the error. For symlinks, log at debug level, as before.
For 'e', failure is not propagated now. The test is adjusted to match.
I think warning is appropriate in most cases: we do not expect a device node to
be replaced by a different device node or even a non-device file. This would
most likely be an error somewhere. An exception is made for symlinks, which are
mismatched on purpose, for example /etc/resolv.conf. With this patch, we don't
get any warnings with the any of the 74 tmpfiles.d files, which suggests that
increasing the warning levels will not cause too many unexpected warnings. If
it turns out that there are valid cases where people have expected mismatches
for non-symlink types, we can always decrease the log levels again.
Quoting of values differs between distros: Fedora doesn't quote the ID_
fields, but CentOS does.
Adjust the test checks to account for this.
Fixes#19242
Also add "system" in the messages, because we set the internal value,
and are just skipping the setting of the external value, so the message
could be confusing without that clarification.
We didn't document this behaviour one way or another, so I think it's
OK to change. All callers do the NULL check before callling this to avoid
the assert warning, so it seems reasonable to do it internally.
sd_bus_can_send() is similar, but there we expressly say that an
error is returned on NULL, so I didn't change it.
Also use standard error loggin/return pattern.
Only cursory tested, by checking that with a simple config file
the array is the same before/after. Not tested with actual scsi
rules and devices, due to missing hardware.
Some static analyzers (lgtm) warn against using non-re-entrant functions,
even though at the moment this code is not multi-threaded, just switch to
format_timestamp.
The warning was disabled in 8794164fed to avoid
false positives. But it is useful in finding errors, even if it sometimes
results in untrue warnings (c.f. 77fac974fe, da46a1bc3c).
After #19168, #19169, and #19175, there are no warnings with
-Dbuildtype=debug-optimized/-O2 and gcc-11.0.1-0.3.fc34.x86_64. Warnings
are reenabled for -O[23]
-O0 is good for development, and -O2 is the default optimization level for
Fedora package builds. -Os, -O3, -O1, and -Og still generate some warnings. In
fact, with -Os the number of warnings seems completely hopeless. Dozens and
dozens.