Re: [LFS Trac] #5960: Consider moving libseccomp to LFS
LFS Trac ([email protected] via lfs-book Mailing List) <[email protected]> Mon, 22 Jun 2026 01:57:34 -0000
| Newsgroups | gmane.linux.lfs.book |
|---|---|
| Message-ID | <[email protected]> |
#5960: Consider moving libseccomp to LFS
-------------------------+-----------------------
Reporter: Bruce Dubbs | Owner: lfs-book
Type: enhancement | Status: new
Priority: normal | Milestone: 13.1
Component: Book | Version: git
Severity: normal | Resolution:
Keywords: |
-------------------------+-----------------------
Comment (by Xi Ruoyao):
See src/seccomp.c for how it's used.
I'm really not a fan of "seccomp sandboxing." Quickly reading the code I
could find something problematic:
{{{
/* Newer variants we don't use. ENOSYS lets glibc fall back. */
ERRNO_RULE(openat2);
ERRNO_RULE(faccessat2);
ERRNO_RULE(close_range);
}}}
The expectation is simply incorrect on LFS: glibc will *not* fall back for
the faccessat2 and close_range cases, as we have --enable-kernel=5.10
which disables the falling back routine for them.
This is why IMO seccomp sandboxing is wrong from day 0: it assumes
implementation details which should be a freedom of the maintainers of
*other* packages.
I'd not really object the move though as a file built with libseccomp
seems still working on my system. Just expressing my dislike of seccomp.
--
Ticket URL: <https://wiki.linuxfromscratch.org/lfs/ticket/5960#comment:1>
LFS Trac <https://wiki.linuxfromscratch.org/lfs/>
Linux From Scratch: Your Distro, Your Rules.
--
http://lists.linuxfromscratch.org/sympa/info/lfs-book
Unsubscribe: See the above information page