Take some of the same rule structure from 60-persistent-input.rules, and
apply it to hidraw devices in 60-persistent-hidraw.rules.
Since one of the motivations for this is being able to easily reference
FIDO tokens, add a special case when ID_FIDO_TOKEN==1, and add 'fido'
to the symlink.
The dbus property getter for DefaultRoute does not simply check
link->default_route. Instead, if l->default_route is not explicitly
configured, it checks dns_scope_is_default_route(l->unicast_scope).
Add a link_get_default_route() helper with this logic so that it can be
used for consistency.
We check this by opening a UDP socket and attempting to connect. We do
not send any traffic on it, but this will tell us if there are routes to
the DNS server.
This will be used in a later commit.
No functional change. Make it more clear that these varlink connections
are subscribed to query results. This prepares for adding SubscribeDNS
to the varlink API.
The varlink method io.systemd.Machine.Register() is in v256, hence type
of "leader" cannot be changed.
Let's revert the change by 755cb018c9, and
introduce another field "leaderProcessId", which takes detailed information
of the process.
Fixes a regression caused by 755cb018c9.
Fixes#36155.
With the following, now preferred source address is set to the DHCP
address.
====
[Route]
Gatewa=_dhcp4
Table=100
====
Before:
====
$ ip route show table 100 default
default via 192.168.0.1 dev eth0 proto dhcp metric 1024
====
After:
====
$ ip route show table 100 default
default via 192.168.0.1 dev eth0 proto dhcp src 192.168.0.100 metric 1024
====
To avoid the assignment, this also introduces PreferredSource=no.
Previously, the following setting
====
[Route]
Gateway=_dhcp4
Table=100
====
only configured the route in the specified table. But it was mostly
useless. This makes prefix route and route to the gateway are also
configured in the specified table.
Before:
====
$ ip route show table 100
default via 192.168.0.1 dev eth0 proto dhcp metric 1024
====
After:
====
$ ip route show table 100
default via 192.168.0.1 dev eth0 proto dhcp metric 1024
192.168.0.0/24 dev eth0 proto dhcp src 192.168.0.100 metric 1024
192.168.0.1 dev eth0 proto dhcp scope link src 192.168.0.100 metric 1024
====
If Gateway=_dhcp4/_ra, the route will be anyway configured with
NETWORK_CONFIG_SOURCE_DHCP4/_NDISC. See dhcp4_request_route() and
ndisc_route_prepare().
This is mostly for avoiding link_drop_routes(), which drops unnecessary static
and/or foreign routes, unexpectedly filtering an existing route with the
route specified with Gateway=_dhcp4/_ra.
tty_is_vc() is more often than not used for simple "categorization"
than validity check. E.g. in logind, we first recognize the tty
"looks like vc", and then use vtnr_from_tty() where range check
is performed and vtnr is extracted. In such cases, we want to reject
invalid vtnr from clients rather than silently carry on, hence
let's remove bound check in tty_is_vc().
Fixes#36166
Replaces #36167 and #36175
This introduces libmount_parse_mountinfo() and libmount_parse_with_utab().
The former one parses only mountinfo, but the latter one also parse
utab. Hopefully this avoids pitfalls like issue #35949.
Now that nspawn can run unprivileged off directory trees owned by
the new "foreign" UID range let's make sure homed actually allows
files owned by that range in the home directories.
This is not enough to make nspawn just work in homed home dirs
unfortunately though. that's because homed applies an idmapping, and
nspawn would need to then to take that idmapped mount and apply another
one, and the kernel simply doesn't support stacked idmapped mounts.
There's work ongoing to address that in the kernel.
However, this is a first step, and should be enough to make things just
work should the kernel eventually support stacked idmapped mounts.
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