Bug 2148753

Summary:	'file' is built without seccomp support
Product:	[Fedora] Fedora	Reporter:	Richard W.M. Jones <rjones>
Component:	file	Assignee:	Vincent Mihalkovič <vmihalko>
Status:	CLOSED WONTFIX	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	38	CC:	jkaluza, kdudka, lzaoral, odubaj, svashisht, vmihalko
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2023-09-11 15:02:05 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Richard W.M. Jones 2022-11-27 17:55:39 UTC

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

Comment 1 Ben Cotton 2023-02-07 15:11:27 UTC

This bug appears to have been reported against 'rawhide' during the Fedora Linux 38 development cycle.
Changing version to 38.

Comment 2 Lukáš Zaoral 2023-09-11 15:02:05 UTC

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/