Libguestfs - Sep 2023 - regression: file does not understand the -S option

Recently a commit was added to call 'file -zSb' instead of 'file
-zb'.

This causes a regression on Leap 15 (but not on Tumbleweed), because
file 5.32 does not understand the -S option.

How can this be fixed properly, to handle both cases either at runtime
or at buildtime?


Thanks,
Olaf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: Digitale Signatur von OpenPGP
URL:
<http://listman.redhat.com/archives/libguestfs/attachments/20230920/2661f2dc/attachment.sig>

On 9/20/23 23:42, Olaf Hering wrote:
> Recently a commit was added to call 'file -zSb' instead of
'file -zb'.
> 
> This causes a regression on Leap 15 (but not on Tumbleweed), because
> file 5.32 does not understand the -S option.
> 
> How can this be fixed properly, to handle both cases either at runtime
> or at buildtime?
This is likely from commit 23986d3c4f4d ("file: Use -S option with
-z",
2022-11-28).

Does your error output contain

  file: invalid option -- 'S'

?

If it does, then I think we could modify "daemon/file.ml" and
"daemon/filearch.ml". Try "file" with the current options,
and if
there's a failure, and stderr contains the above string, retry without -S.

Unfortunately, this is a bit messy. We'd probably want to cache the
availability of -S. Also, because this logic is used from multiple
places, we'd first have to factor out the current "file"
invocation --
minimally, try to rebase the "file" invocation in
"daemon/filearch.ml"
to the interface exposed by "daemon/file.mli".

Laszlo

> 
> 
> Thanks,
> Olaf
> 
> 
> _______________________________________________
> Libguestfs mailing list
> Libguestfs at redhat.com
> https://listman.redhat.com/mailman/listinfo/libguestfs

On Wed, Sep 20, 2023 at 11:42:55PM +0200, Olaf Hering
wrote:
> Recently a commit was added to call 'file -zSb' instead of
'file -zb'.
> 
> This causes a regression on Leap 15 (but not on Tumbleweed), because
> file 5.32 does not understand the -S option.
> 
> How can this be fixed properly, to handle both cases either at runtime
> or at buildtime?
The background to this was:

  https://github.com/libguestfs/libguestfs/issues/100

It took a while to work out what was going on in the original bug
report, but it turned out that Arch (IIRC) enabled the seccomp feature
in the 'file' command.  This filters what system calls 'file' is
allowed to make, which strengthens security as 'file' is often run on
untrusted inputs.

Unfortunately the seccomp rules for 'file' don't cope with running
external programs (ie. 'file -z' which runs zcat).  We filed a bug to
try to get that fixed:

  https://bugzilla.redhat.com/show_bug.cgi?id=2148753
  https://bugs.astron.com/view.php?id=406

but the fix to seccomp policy was rejected recently in both Fedora &
upstream.

The patch we added to libguestfs turns off seccomp sandboxing, both
because it's broken (see above) and because we don't really need it as
we run stuff in a virtual machine already:

 
https://github.com/libguestfs/libguestfs/commit/23986d3c4f4d1f9cbac44cc743d3e6af721e4237

I didn't realise there were distros that lack support for the
'file -S' option.

So I guess the fix is to detect if 'file' has the -S option ...
I think we can just grep 'file --help' for the -S / --no-sandbox
option.  Let me try for a patch now.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW