Let's a concept of "rate limiting" to event sources: if specific event
sources fire too often in some time interval temporarily take them
offline, and take them back online once the interval passed.
This is a simple scheme of avoiding starvation of event sources if some
event source fires too often.
This introduces the new conceptual states of "offline" and "online" for
event sources: an event source is "online" only when enabled *and* not
ratelimited, and offline in all other cases. An event source that is
online hence has its fds registered in the epoll, its signals in the
signalfd and so on.
So far we used these fields to organize the earliest/latest timer event
priority queue. In a follow-up commit we want to introduce ratelimiting
to event sources, at which point we want any kind of event source to be
able to trigger time wakeups, and hence they all need to be included in
the earliest/latest prioqs. Thus, in preparation let's make this
generic.
No change in behaviour, just some shifting around of struct members from
the type-specific to the generic part.
sd_event_prepare() invokes callbacks that might drop the last user ref
on our event loop. Let's make sure we keep an explicit ref around it, so
that we won't end up with an invalid pointer. Similar in sd_event_run().
Basically, any function that is publically callable that might end up
invoking callbacks should ref the relevant objects to be protected
against callbacks destroying these objects while we still want to access
them. We did this correctly in sd_event_dispatch() and sd_event_loop(),
but these are not the only ones which are callable from the outside.
The comment is pointless, ECC systematically doesn't allow
encryption/decryption directly, only RSA does that. If you want to use
ECC for asymmetric encryption/decryption you have to combine it with key
exchange scheme and symmetric scheme. This all is not a limitation of
the Yubikey, hence don't claim so. It's just how ECC is.
Let's move the 3rd way how cryptsetup acquires key files to
read_file_full() too.
Since load_key_file()'s raison d'etre now is just the search path logic,
let's rename the function to find_key_file().
Previously, we'd load the file with libcryptsetup's calls. Let's do that
in our own, so that we can make use of READ_FULL_FILE_CONNECT_SOCKET,
i.e. read in keys via AF_UNIX sockets, so that people can plug key
providers into our logic.
This provides functionality similar to Debian's keyscript= crypttab
option (see → #3007), as it allows key scripts to be run as socket
activated services, that have stdout connected to the activated socket.
In contrast to traditional keyscript= support this logic runs stuff out
of process however, which is beneficial, since it allows sandboxing and
similar.
Commit 428a9f6f1d freed u->pids which is
problematic since the references to this unit in m->watch_pids were no more
removed when the unit was freed.
This patch makes sure to clean all this refs up before freeing u->pids by
calling unit_unwatch_all_pids().
Zbigniew Jędrzejewski-Szmek
Lennart Poettering
Michal Sekletár
Franck Bui
Vito Caputo
Pavel Sapezhko
igo95862
Piotr Drąg
Michał Kopeć
Yu Watanabe
nihilix-melix
Frantisek Sumsal
Konomi