Description of problem: Originally found / reported to me by Toolybird here: https://github.com/libguestfs/libguestfs/issues/100#issuecomment-1328182986 In Fedora, it seems as if we intend to use seccomp support with file. In the past we have added patches to fix seccomp support. However currently file is compiled without seccomp support: checking for seccomp_init in -lseccomp... no I think this is just a missing dependency. If you compile the unmodified package locally with a machine that has libseccomp-devel installed then it works. Version-Release number of selected component (if applicable): file-5.42-4.fc38 How reproducible: 100% Steps to Reproduce: 1. See latest build log: https://koji.fedoraproject.org/koji/buildinfo?buildID=2036332
This bug appears to have been reported against 'rawhide' during the Fedora Linux 38 development cycle. Changing version to 38.
Unfortunately, the seccomp support in file would need a major overhaul for it to be enabled by default. `file -z` uses external tools like gzip or unzip to peek inside the archives and this option is not particularly usable when seccomp is enabled because file would need to list every single syscall that those tools may depend on as described in the help of the -S option: -S, --no-sandbox On systems where libseccomp (https://github.com/seccomp/libseccomp) is available, the -S option disables sandboxing which is enabled by default. This option is needed for file to execute external decompressing programs, i.e. when the -z option is specified and the built-in decompressors are not available. On systems where sandboxing is not available, this option has no effect. Enabling seccomp would break scripts that calls `-z` without `-S` which I believe is not acceptable. If you still think it is a good idea to have it enabled, please, file a Fedora Change Proposal [1] so that it can be evaluated by the whole Fedora community and FESCo. Regards, Lukas [1] https://docs.fedoraproject.org/en-US/program_management/changes_policy/