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