diff options
author | Paul Moore <paul@paul-moore.com> | 2020-07-26 11:01:49 -0400 |
---|---|---|
committer | Paul Moore <paul@paul-moore.com> | 2020-08-18 11:44:44 -0400 |
commit | ce314fe4111887c593e3c6b17c60d93bc6ab66b9 (patch) | |
tree | 41c2c6b5bf4e9c1ead1e3f8122e5ff5ff6b5f465 /doc | |
parent | bee43d3e884788569860a384e6a38357785a3995 (diff) | |
download | libseccomp-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.3 | 10 | ||||
-rw-r--r-- | doc/man/man3/seccomp_notify_alloc.3 | 3 |
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 () |