Currently homed scans /home/ via inotify for new .home + .homedir/
popping up to register as local users. Let's also add an explicit way to
request this form of "adoption": a bus call that takes a path and that
makes a home dir activatable locally.
(Usecase: you cross boot between two systems – let's say your traditional
fedora and your ParticleOS – and want to use the same homedir from both:
simply mount the /home dir from the other somewhere, and then hit
"homectl adopt /somewhere/lennart.home" and you have the user locally
too).
To resolve conflict with sys/mount.h and linux/mount.h or linux/fs.h.
The conflict between sys/mount.h and linux/mount.h is resolved in
glibc-2.37 (774058d72942249f71d74e7f2b639f77184160a6), but our baseline
is still glibc-2.31. Also, even with the version or newer, still
sys/mount.h conflicts with linux/fs.h, which is included by
linux/btrfs.h.
This introduces our own implementation of sys/mount.h, that can be
simultaneously included with linux/mount.h and linux/fs.h. This also
imports linux/fs.h, linux/mount.h, and several other dependent headers.
The introduced sys/mount.h header itself may not be enough simple, but
by using the header, we can drop most of workarounds in other source files.
In various scenarios we invoke containers with access to the kernel
keyring blocked. Let's make sure we can handle this properly: when the
invocation ID is stored in in the kernel keyring and we try to read it
and get EPERM we should handle it gracefully, like EOPNOTSUPP.
This reverts commit b6a2df6307.
The functionality is entirely redundant, we already have
sd_json_variant_filter() which does the same, and is in fact even more
powerful, since it takes a list instead of a single field to remove.
Hinted by CID#1591563 but the issue is different -- when
sd_event_source_set_destroy_callback() fails, we would use the old
n_sources value and possibly missing sd_event_source_unref() of the last
added source.
Follow-up for c6cc7efcd3
The documentation has been updated, but apparently I forgot
to update the function itself...
Also, actually pass flags to pidfd_send_signal(). Previously
it was spuriously ignored.
We want systemd-pty-forward to be something that can be dropped in
somewhere without too much thought. To enable this, let's make sure
we forward various signals to the forked process. This makes sure that
any signals are delivered to the actual child process regardless of whether
it's running within systemd-pty-forward or not.
- drop unnecessary one line function dump_device_action_table(),
- make parse_device_action() log about invalid action string,
- rename output argument of parse_device_action().
"Recently" (as of 5.18) the Linux kernel gained the ability of locking
bridge ports to restrict network access to authenticated hosts only.
This is implemented by disabling automated learning and dropping
incoming traffic from unknown hosts. User space is then expected to add
fdb entries for authenticated hosts. Once a fdb entry exist, traffic for
that host will be forwarded as expected.
This was later extended with "Mac Authentication Bypass", where the
locking was extended to fdb entries. In this mode the kernel adds fdb
entries again automatically, but they are locked by default.
To properly configure this, add two network options and one netdev
option:
* `LinkLocalLearning=` to prevent the kernel from creating unlocked
entries based on link-local traffic, which would bypass any
authentication. Needed when enabling learning on a locked port.
* `Locked=` to allow setting a bridge port to locked.
* `MACAuthenticationBypass=` to allow enabling Mac Authentication
Bypass on a port. Requires learning to be enabled on the port as well
(and consequently `LinkLocalLearning` disabled on the bridge).
An authenticator (e.g. hostapd) is still needed to do the actual
authentication, the kernel only provides the access control.
Since linux commit a35ec8e38cdd1766f29924ca391a01de20163931 ("bridge:
Add MAC Authentication Bypass (MAB) support"), included since v6.2, it
is possible to enable MAC Authentication Bypass for bridge ports. In
this mode the locked port learns again, but the learned fdb entries are
locked, allowing user space to unlock hosts based seen MAC addresses.
This requires learning to be enabled on the port, and link-local
learning disabled for the bridge.
Add support to systemd-network for setting the new attribute for bridge
ports.
Since linux commit a21d9a670d81103db7f788de1a4a4a6e4b891a0b ("net:
bridge: Add support for bridge port in locked mode"), included since
v5.18, it is possible to set bridge ports to locked.
Locked ports do not learn automatically, and discard any traffic from
unknown source MACs. To allow traffic, the userspace authenticator is
expected to create fdb entries for authenticated hosts.
Add support to systemd-network for setting the new attribute for bridge
ports.
An object json is a set of key and value pair, hence has its number of
element is multiple of two, and we know at least two elements there.
Follow-up for b6a2df6307.
Fixes CID#1590724