summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorPaul Moore <paul@paul-moore.com>2020-07-26 11:01:49 -0400
committerPaul Moore <paul@paul-moore.com>2020-08-18 11:44:44 -0400
commitce314fe4111887c593e3c6b17c60d93bc6ab66b9 (patch)
tree41c2c6b5bf4e9c1ead1e3f8122e5ff5ff6b5f465 /doc
parentbee43d3e884788569860a384e6a38357785a3995 (diff)
downloadlibseccomp-ce314fe4111887c593e3c6b17c60d93bc6ab66b9.tar.gz
all: only request the userspace notification fd once
It turns out that requesting the seccomp userspace notifcation fd more than once is a bad thing which causes the kernel to complain (rightfully so for a variety of reasons). Unfortunately as we were always requesting the notification fd whenever possible this results in problems at filter load time. Our solution is to move the notification fd out of the filter context and into the global task context, using a newly created task_state structure. This allows us to store, and retrieve the notification outside the scope of an individual filter context. It also provides some implementation improvements by giving us a convenient place to stash all of the API level related support variables. We also extend the seccomp_reset() API call to reset this internal global state when passed a NULL filter context. There is one potential case which we don't currently handle well: threads. At the moment libseccomp is thread ignorant, and that works well as the only global state up to this point was the currently supported API level information which was common to all threads in a process. Unfortunately, it appears that the notification fd need not be common to all threads in a process, yet this patch treats it as if it is common. I suspect this is a very unusual use case so I decided to keep this patch simple and ignore this case, but in the future if we need to support this properly we should be able to do so without API changes by keeping an internal list of notification fds indexed by gettid(2). This fixes the GitHub issue below: * https://github.com/seccomp/libseccomp/issues/273 Reported-by: Tobias Stoeckmann <tobias@stoeckmann.org> Acked-by: Tom Hromatka <tom.hromatka@oracle.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
Diffstat (limited to 'doc')
-rw-r--r--doc/man/man3/seccomp_init.310
-rw-r--r--doc/man/man3/seccomp_notify_alloc.33
2 files changed, 11 insertions, 2 deletions
diff --git a/doc/man/man3/seccomp_init.3 b/doc/man/man3/seccomp_init.3
index 3ab68fe..87520cd 100644
--- a/doc/man/man3/seccomp_init.3
+++ b/doc/man/man3/seccomp_init.3
@@ -36,7 +36,15 @@ The
function releases the existing filter context state before reinitializing it
and can only be called after a call to
.BR seccomp_init ()
-has succeeded.
+has succeeded. If
+.BR seccomp_reset ()
+is called with a NULL filter, it resets the library's global task state;
+normally this is not needed, but it may be required to continue using the
+library after a
+.BR fork ()
+or
+.BR clone ()
+call to ensure the API level and user notification state is properly reset.
.P
When the caller is finished configuring the seccomp filter and has loaded it
into the kernel, the caller should call
diff --git a/doc/man/man3/seccomp_notify_alloc.3 b/doc/man/man3/seccomp_notify_alloc.3
index 50c8970..cb1c048 100644
--- a/doc/man/man3/seccomp_notify_alloc.3
+++ b/doc/man/man3/seccomp_notify_alloc.3
@@ -59,7 +59,8 @@ returns the notification fd of a filter after it has been loaded.
.\" //////////////////////////////////////////////////////////////////////////
The
.BR seccomp_notify_fd ()
-returns the notification fd of the loaded filter.
+returns the notification fd of the loaded filter, -1 if a notification fd has
+not yet been created, and -EINVAL if the filter context is invalid.
.P
The
.BR seccomp_notify_id_valid ()