diff --git a/TODO b/TODO
index 72c225dc44..dfc3e97ba6 100644
--- a/TODO
+++ b/TODO
@@ -383,8 +383,6 @@ Features:
credential (would probably require some binary that converts credential to
User= parameter?
-* sd-varlink should probably enforce a limit on queued outgoing replies
-
* systemd-firstboot: optionally install an ssh key for root for offline use.
* Allocate UIDs/GIDs automatically in userdbctl load-credentials if none are
diff --git a/man/rules/meson.build b/man/rules/meson.build
index 0b930d3beb..433fffc571 100644
--- a/man/rules/meson.build
+++ b/man/rules/meson.build
@@ -889,6 +889,8 @@ manpages = [
'sd_uid_get_sessions',
'sd_uid_is_on_seat'],
'HAVE_PAM'],
+ ['sd_varlink_push_fd', '3', ['sd_varlink_push_dup_fd'], ''],
+ ['sd_varlink_send', '3', ['sd_varlink_sendb', 'sd_varlink_sendbo'], ''],
['sd_varlink_set_description', '3', ['sd_varlink_get_description'], ''],
['sd_watchdog_enabled', '3', [], ''],
['shutdown', '8', [], ''],
diff --git a/man/sd_varlink_push_fd.xml b/man/sd_varlink_push_fd.xml
new file mode 100644
index 0000000000..d689052768
--- /dev/null
+++ b/man/sd_varlink_push_fd.xml
@@ -0,0 +1,134 @@
+
+
+
+
+
+
+
+ sd_varlink_push_fd
+ systemd
+
+
+
+ sd_varlink_push_fd
+ 3
+
+
+
+ sd_varlink_push_fd
+ sd_varlink_push_dup_fd
+
+ Submit a file descriptor to send along with the next outgoing Varlink message
+
+
+
+
+ #include <systemd/sd-varlink.h>
+
+
+ int sd_varlink_push_fd
+ sd_varlink *link
+ int fd
+
+
+
+ int sd_varlink_push_dup_fd
+ sd_varlink *link
+ int fd
+
+
+
+
+
+ Description
+
+ sd_varlink_push_fd() submits a file descriptor to send along with the next
+ outgoing Varlink message. Takes a Varlink connection object and a file descriptor as parameter. The file
+ descriptor is not duplicated, and hence ownership of the file descriptor is passed to the Varlink
+ connection object (only on success; on failure the caller retains ownership). Once the file descriptor
+ has been written to the underlying transport socket it is automatically closed. The calling application
+ code should not touch the file descriptor or close it on its own, otherwise it will interfere with the
+ Varlink protocol implementation. This call is only supported if the backing transport supports file
+ descriptor passing (effectively this means the functionality is supported on local
+ AF_UNIX only), and the concept is not part of the Varlink protocol, but simply a
+ feature of the underlying transport.
+
+ sd_varlink_push_dup_fd() is identical to
+ sd_varlink_push_fd(), except that the file descriptor is duplicated automatically,
+ and the calling application code hence retains ownership of the provided file descriptor, and must close
+ it on its own.
+
+ Note that file descriptor passing is only permitted after a call to
+ sd_varlink_set_allow_fd_passing_output() that enables it, otherwise these calls will
+ fail with -EPERM.
+
+ Note that on Linux a maximum of 253 file descriptors may be enqueued on
+ AF_UNIX sockets at once. Attempting to enqueue more on a single Varlink message will
+ fail with -ENOBUFS.
+
+
+
+ Return Value
+
+ On success, sd_varlink_push_fd() and
+ sd_varlink_push_dup_fd() return a non-negative integer. On failure, they return a
+ negative errno-style error code.
+
+
+ Errors
+
+ Returned errors may indicate the following problems:
+
+
+
+ -EINVAL
+
+ An argument is invalid.
+
+
+
+ -EBADF
+
+ The provided file descriptor is not valid.
+
+
+
+ -EPERM
+
+ File descriptor passing has not been enabled via
+ sd_varlink_set_allow_fd_passing_output().
+
+
+
+ -ENOBUFS
+
+ The maximum of 253 file descriptors have already been submitted for the next
+ outgoing Varlink message, no further descriptors may be enqueued for this message.
+
+
+
+ -ENOMEM
+
+ Memory allocation failed.
+
+
+
+
+
+
+
+
+ History
+ sd_varlink_push_fd() and sd_varlink_push_dup_fd() were added in version 257.
+
+
+
+ See Also
+
+
+ systemd1
+ sd-varlink3
+
+
+
diff --git a/man/sd_varlink_send.xml b/man/sd_varlink_send.xml
new file mode 100644
index 0000000000..2c6b998ccf
--- /dev/null
+++ b/man/sd_varlink_send.xml
@@ -0,0 +1,151 @@
+
+
+
+
+
+
+
+ sd_varlink_send
+ systemd
+
+
+
+ sd_varlink_send
+ 3
+
+
+
+ sd_varlink_send
+ sd_varlink_sendb
+ sd_varlink_sendbo
+
+ Enqueues a Varlink method call, not expecting a reply
+
+
+
+
+ #include <systemd/sd-varlink.h>
+
+
+ int sd_varlink_send
+ sd_varlink *link
+ const char *method
+ sd_json_variant *parameters
+
+
+
+ int sd_varlink_sendb
+ sd_varlink *link
+ const char *method
+ …
+
+
+
+ int sd_varlink_sendbo
+ sd_varlink *link
+ const char *method
+ …
+
+
+
+
+
+ Description
+
+ sd_varlink_send() submits a method call via a Varlink connection. It takes the
+ Varlink connection object, a method name as string parameter, and a JSON object containing the parameters
+ to pass as function parameters. This call is asynchronous: the message will not be delivered immediately
+ but only once
+ sd_varlink_process3 is
+ invoked (which will happen automatically in one of the following event loop iterations if the Varlink
+ connection is attached to an even loop).
+
+ sd_varlink_sendb() is similar to sd_varlink_send(), but
+ instead of expecting a fully constructed sd_json_variant object carrying the parameters,
+ this object is constructed on-the-fly directly from the parameter list, in a style identical to
+ sd_json_build3.
+
+ sd_varlink_sendbo() is identical to sd_varlink_sendb(),
+ but an enclosing object is implicitly added, so that the parameter list is expected to consist of field
+ pairs only. For details about the expected argument list, see
+ sd_json_buildo3.
+
+ Use sd_varlink_send(), sd_varlink_sendb() and
+ sd_varlink_sendbo() only if no method call results are required, as they neither
+ provide return parameters nor success/failure information. Use
+ sd_varlink_call3 (and
+ related calls) to submit a method call synchronously, returning the server's response.
+
+
+
+ Return Value
+
+ On success, sd_varlink_send(), sd_varlink_sendb() and
+ sd_varlink_sendbo() return a non-negative integer. On failure, they return a
+ negative errno-style error code.
+
+
+ Errors
+
+ Returned errors may indicate the following problems:
+
+
+
+ -EINVAL
+
+ An argument is invalid.
+
+
+
+ -ENOMEM
+
+ Memory allocation failed.
+
+
+
+ -ENOTCONN
+
+ The Varlink connection object is not connected.
+
+
+
+ -EBUSY
+
+ The Varlink connection object is already used for other purposes, i.e. executing a
+ method call or similar.
+
+
+
+ -ENOBUFS
+
+ The internal limit of queued messages for the Varlink connection has been
+ reached. This limit is set very high, and hitting it typically indicates that the Varlink
+ connection object is stalled — possibly because sd_varlink_process() has not
+ been called regularly enough, or because the peer is not processing any queued messages. This limit
+ is a safety precaution to ensure a stalled peer will not result in unbounded memory allocations on
+ the client side.
+
+
+
+
+
+
+
+
+ History
+ sd_varlink_send(), sd_varlink_sendb(),
+ sd_varlink_sendbo() were added in version 257.
+
+
+
+ See Also
+
+
+ systemd1
+ sd-varlink3
+ sd_varlink_call3
+ sd_varlink_build3
+
+
+
diff --git a/man/sd_varlink_set_description.xml b/man/sd_varlink_set_description.xml
index e64cd8a5ac..67817d3c09 100644
--- a/man/sd_varlink_set_description.xml
+++ b/man/sd_varlink_set_description.xml
@@ -24,7 +24,7 @@
- #include <systemd/sd-link.h>
+ #include <systemd/sd-varlink.h>
int sd_varlink_set_description
diff --git a/src/libsystemd/sd-varlink/sd-varlink.c b/src/libsystemd/sd-varlink/sd-varlink.c
index 57d106a390..bf38564783 100644
--- a/src/libsystemd/sd-varlink/sd-varlink.c
+++ b/src/libsystemd/sd-varlink/sd-varlink.c
@@ -41,6 +41,7 @@
#define VARLINK_BUFFER_MAX (16U*1024U*1024U)
#define VARLINK_READ_SIZE (64U*1024U)
#define VARLINK_COLLECT_MAX 1024U
+#define VARLINK_QUEUE_MAX (64U*1024U)
static const char* const varlink_state_table[_VARLINK_STATE_MAX] = {
[VARLINK_IDLE_CLIENT] = "idle-client",
@@ -631,6 +632,7 @@ static void varlink_clear(sd_varlink *v) {
LIST_CLEAR(queue, v->output_queue, varlink_json_queue_item_free);
v->output_queue_tail = NULL;
+ v->n_output_queue = 0;
v->event = sd_event_unref(v->event);
@@ -1946,6 +1948,9 @@ static int varlink_enqueue_json(sd_varlink *v, sd_json_variant *m) {
if (v->n_pushed_fds == 0 && !v->output_queue)
return varlink_format_json(v, m);
+ if (v->n_output_queue >= VARLINK_QUEUE_MAX)
+ return -ENOBUFS;
+
/* Otherwise add a queue entry for this */
q = varlink_json_queue_item_new(m, v->pushed_fds, v->n_pushed_fds);
if (!q)
@@ -1955,6 +1960,7 @@ static int varlink_enqueue_json(sd_varlink *v, sd_json_variant *m) {
LIST_INSERT_AFTER(queue, v->output_queue, v->output_queue_tail, q);
v->output_queue_tail = q;
+ v->n_output_queue++;
return 0;
}
@@ -1968,6 +1974,9 @@ static int varlink_format_queue(sd_varlink *v) {
while (v->output_queue) {
_cleanup_free_ int *array = NULL;
+
+ assert(v->n_output_queue > 0);
+
VarlinkJsonQueueItem *q = v->output_queue;
if (v->n_output_fds > 0) /* unwritten fds? if we'd add more we'd corrupt the fd message boundaries, hence wait */
@@ -1992,6 +2001,7 @@ static int varlink_format_queue(sd_varlink *v) {
LIST_REMOVE(queue, v->output_queue, q);
if (!v->output_queue)
v->output_queue_tail = NULL;
+ v->n_output_queue--;
varlink_json_queue_item_free(q);
}
@@ -3112,8 +3122,8 @@ _public_ int sd_varlink_push_fd(sd_varlink *v, int fd) {
if (!v->allow_fd_passing_output)
return -EPERM;
- if (v->n_pushed_fds >= INT_MAX)
- return -ENOMEM;
+ if (v->n_pushed_fds >= SCM_MAX_FD) /* Kernel doesn't support more than 253 fds per message, refuse early hence */
+ return -ENOBUFS;
if (!GREEDY_REALLOC(v->pushed_fds, v->n_pushed_fds + 1))
return -ENOMEM;
diff --git a/src/libsystemd/sd-varlink/varlink-internal.h b/src/libsystemd/sd-varlink/varlink-internal.h
index 377f8cfae4..5ff233f210 100644
--- a/src/libsystemd/sd-varlink/varlink-internal.h
+++ b/src/libsystemd/sd-varlink/varlink-internal.h
@@ -142,6 +142,7 @@ struct sd_varlink {
* with preceding or following messages. */
LIST_HEAD(VarlinkJsonQueueItem, output_queue);
VarlinkJsonQueueItem *output_queue_tail;
+ size_t n_output_queue;
/* The fds to associate with the next message that is about to be enqueued. The user first pushes the
* fds it intends to send via varlink_push_fd() into this queue, and then once the message data is