Consider moving libseccomp to LFS

[Bruce Dubbs]

This request came from Chase Knowlden on lfs-dev. I checked and file can use libseccomp, but how it is used is not obvious without digging into the code.

Moving a file from one book to the other is not trivial. Many packages have to be touched. Twelve BLFS packages mention libseccomp and in addition to adding the new page to LFS, at least five additional files need to be updated in LFS.

Note that libseccomp now lists three optional dependencies in BLFS and one external optional dependency,

The question is whether the benefit of moving the package is worth the effort.

[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.

[zeckma]

Its use in LFS just for File and the way it's used doesn't seem like it's worth the effort. To me, it's a perfect fit for BLFS, but for LFS, it's just another extra package that doesn't really need to be there.

And thanks Xi for sharing that perspective. It seems like it could cause more issues than it's worth.

[Bruce Dubbs]

I agree. For LFS is does not appear to add anything that file would use. Closing as wontfix.