lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <87seurv5hb.fsf@oldenburg.str.redhat.com>
Date: Mon, 26 Aug 2024 14:22:24 +0200
From: Florian Weimer <fweimer@...hat.com>
To: fuse-devel@...ts.sourceforge.net, linux-fsdevel@...r.kernel.org,
 linux-api@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Recommended version handshake for FUSE clients

I cannot use libfuse, so I'm writing my own mini-wrapper directly on top
of the kernel interface.  For the major version handshake, I understand
that I need to reply with version 7 if a later major version is
required.  But what to do about the minor version?

Should I use the minimum version that is expected to work (because there
have not been any struct layout changes since)?  I think this could end
up problematic if some struct sizes have grown between the known-good
minimum version and the <linux/fuse.h> version, something that a future
<linux/fuse.h> version might bring.

Or should I just send back FUSE_KERNEL_MINOR_VERSION from the system
version of <linux/fuse.h>?  I think this assumes that merely increasing
the minor version does not result in behavioral changes (such as
additonal FUSE events being generated that the current code knows
nothing about).

The code only has to run on the system that it was compiled on and
possibly newer kernels.  Going back to older kernels is not needed.  But
I also expect people using a wide range of kernel header versions to
compile this code.

Or perhaps I should bundle some older version of <linux/fuse.h> with my
sources?

Thanks,
Florian


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ