The benefit of using this setting is that user and group IDs, especially dynamic and random
IDs used by DynamicUser=, can be used in firewall configuration easily.
Example:
```
[Service]
NFTSet=user:inet:filter:serviceuser
```
Corresponding NFT rules:
```
table inet filter {
set serviceuser {
typeof meta skuid
}
chain service_output {
meta skuid @serviceuser accept
drop
}
}
```
```
$ cat /etc/systemd/system/dunft.service
[Service]
DynamicUser=yes
NFTSet=user:inet:filter:serviceuser
ExecStart=/bin/sleep 1000
[Install]
WantedBy=multi-user.target
$ sudo nft list set inet filter serviceuser
table inet filter {
set serviceuser {
typeof meta skuid
elements = { 64864 }
}
}
$ ps -n --format user,group,pid,command -p `systemctl show dunft.service -P MainPID`
USER GROUP PID COMMAND
64864 64864 55158 /bin/sleep 1000
```
New directive `NFTSet=` provides a method for integrating dynamic cgroup IDs
into firewall rules with NFT sets. The benefit of using this setting is to be
able to use control group as a selector in firewall rules easily and this in
turn allows more fine grained filtering. Also, NFT rules for cgroup matching
use numeric cgroup IDs, which change every time a service is restarted, making
them hard to use in systemd environment.
This option expects a whitespace separated list of NFT set definitions. Each
definition consists of a colon-separated tuple of source type (only "cgroup"),
NFT address family (one of "arp", "bridge", "inet", "ip", "ip6", or "netdev"),
table name and set name. The names of tables and sets must conform to lexical
restrictions of NFT table names. The type of the element used in the NFT filter
must be "cgroupsv2". When a control group for a unit is realized, the cgroup ID
will be appended to the NFT sets and it will be be removed when the control
group is removed. systemd only inserts elements to (or removes from) the sets,
so the related NFT rules, tables and sets must be prepared elsewhere in
advance. Failures to manage the sets will be ignored.
If the firewall rules are reinstalled so that the contents of NFT sets are
destroyed, command systemctl daemon-reload can be used to refill the sets.
Example:
```
table inet filter {
...
set timesyncd {
type cgroupsv2
}
chain ntp_output {
socket cgroupv2 != @timesyncd counter drop
accept
}
...
}
```
/etc/systemd/system/systemd-timesyncd.service.d/override.conf
```
[Service]
NFTSet=cgroup:inet:filter:timesyncd
```
```
$ sudo nft list set inet filter timesyncd
table inet filter {
set timesyncd {
type cgroupsv2
elements = { "system.slice/systemd-timesyncd.service" }
}
}
```
This was requested, though I think an issue was never filed. If people are
supposed to invoke it, even for testing, then it's reasonable to make it
"public".
I was missing an example of how to use cryptenroll. We have that, but in
another page. Instead of repeating, let's just direct the user to the right
place.
Also, reformat synopsis to the "official" non-nested syntax.
The tool initially just measured the boot phase, but was subsequently
extended to measure file system and machine IDs, too. At AllSystemsGo
there were request to add more, and make the tool generically
accessible.
Hence, let's rename the binary (but not the pcrphase services), to make
clear the tool is not just measureing the boot phase, but a lot of other
things too.
The tool is located in /usr/lib/ and still relatively new, hence let's
just rename the binary and be done with it, while keeping the unit names
stable.
While we are at it, also move the tool out of src/boot/ and into its own
src/pcrextend/ dir, since it's not really doing boot related stuff
anymore.
I recently tried adding a FIDO2-Device as an unlocking method to the LUKS2 partition containing my Fedora install.
When trying to do this, I stumbled upon the here edited man files detailing how to do this.
I however could not unlock my partition with my FIDO2-Device after editing /etc/crypttab and rebooting.
As I found out after a while, I needed to regenerate / update my currently running / used initramfs (https://unix.stackexchange.com/a/705809).
This would have most likely solved itself for me with the next kernel update install (as far as I understand).
So I propose changing the files edited here to recommend or at least inform the user about this.
Let's replace the "compat" module in our proposed nsswitch.conf
configuration with "files", since it is not 1995 anymore.
Fedora and other distros have deprecated and removed NIS support a while
back. While others still retain some support I am not sure we should
advertise it in our examples. Downstream can of course still use
"compat" instead of "files" if they want to, but let's not confuse
people who don't care about NIS anymore with this.
Also, bring the nsswitch.conf snippet in README in line with what our
man pages say.
Also see: https://fedoraproject.org/wiki/Changes/retire_NIS_user_space_utils
As I noticed a lot of missing information when trying to implement checking
for missing info. I reimplemented the version information script to be more
robust, and here is the result.
Follow up to ec07c3c80b
This adds a new "PollLimit" pair of settings to .socket units, very
similar to existing "TriggerLimit" logic. The differences are:
* PollLimit focusses on the polling on the sockets, and pauses that
temporarily if a ratelimit on that is reached. TriggerLimit otoh
focusses on the triggering effect of socket units, and stops
triggering once the ratelimit is hit.
* While the trigger limit being hit is an action that causes the socket
unit to fail the polling limit being reached will just temporarily
disable polling on the socket fd, and it is resumed once the ratelimit
interval is over.
* When a socket unit operates on multiple socket fds (e,g, ListenStream=
on both some ipv6 and an ipv4 address or so). Then the PollLimit will
be specific to each fd, while the trigger limit is specific to the
whole unit.
Implementation-wise this is mostly a wrapper around sd-event's
sd_event_source_set_ratelimit(), which exposes the desired behaviour
directly.
Usecase for all of this: socket services which when overloaded with
connections should just slow down reception of it, but not fail
persistently.