4:42 p.m.
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
3:21 a.m.
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(a)redhat.com
https://listman.redhat.com/mailman/listinfo/libguestfs
9:36 a.m.
Thu, 21 Sep 2023 10:21:41 +0200 Laszlo Ersek <lersek(a)redhat.com>:
Does your error output contain
file: invalid option -- 'S'
?
Yes, it looks like this:
# /usr/bin/env -i /usr/bin/file -S
/usr/bin/file: invalid option -- 'S'
Usage: file [-bcEhikLlNnprsvzZ0] [--apple] [--extension] [--mime-encoding] [--mime-type]
[-e testname] [-F separator] [-f namefile] [-m magicfiles] file ...
file -C [-m magicfiles]
file [--help]
Olaf
6:25 a.m.
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/23986d3c4f4d1f9cbac44cc74...
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
6:41 a.m.
On Thu, Sep 21, 2023 at 12:25:21PM +0100, Richard W.M. Jones wrote:
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.
Their rationale in that bug makes no sense.
Not allowing 'clone+execve' etc is correct when '-z' is NOT specified
by the user. No argument there.
If '-z' is specified then adding clone+execve etc is the only way it
can work. They should apply a different seccomp filter for '-z' only
which includes clone+execve, etc. Telling people to turn off seccomp
entirely in order to use '-z' is even worse for security than just
allowing clone+execve.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
352
days inactive
353
days old
4 comments
4 participants
participants (4)
-
Daniel P. Berrangé -
Laszlo Ersek -
Olaf Hering -
Richard W.M. Jones