[MIR][FFE] glusterfs

[Andreas Hasenack]

Old MIR is bug #1274247

(launchpad will definitely wrap these lines and break the formatting: if you want, I can post this content elsewhere, like a git repo)

[Availability]
The package glusterfs is already in Ubuntu universe.
The package glusterfs build for the architectures it is designed to work on.
It currently builds and works for architetcures: amd64 arm64 armhf ppc64el riscv64 s390x

Link to package https://launchpad.net/ubuntu/+source/glusterfs

[Rationale]
The package glusterfs is required in Ubuntu main for:
- The package glusterfs will generally be useful for a large part of
  our user base
- Additionally new use-cases enabled by this are:
  - samba clustering support (we carry a packaging delta to disable it in Ubuntu)
  - qemu native glusterfs support (bug #1246924)

[Security]
For the security review, consider the points raised last time this was done, in 2014, when the first MIR was rejected:

https://bugs.launchpad.net/ubuntu/+source/glusterfs/+bug/1274247/comments/14

cppcheck issues were fixed:
https://bugs.launchpad.net/ubuntu/+source/glusterfs/+bug/1274247/comments/19
https://bugzilla.redhat.com/show_bug.cgi?id=1086460

There are some strncat warnings during build, like these:
In file included from /usr/include/string.h:519,
                 from ../../../../libglusterfs/src/glusterfs/glusterfs.h:15,
                 from trash.h:13,
                 from trash.c:10:
In function ‘strncat’,
    inlined from ‘trash_truncate_mkdir_cbk’ at trash.c:1730:13:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:135:10: warning: ‘__strncat_chk’ output may be truncated copying between 0 and 4095 bytes from a string of length 4095 [-Wstringop-truncation]
  135 | return __builtin___strncat_chk (__dest, __src, __len,
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  136 | __glibc_objsize (__dest));
      | ~~~~~~~~~~~~~~~~~~~~~~~~~

and

In file included from /usr/include/string.h:519,
                 from ../../../../libglusterfs/src/glusterfs/glusterfs.h:15,
                 from glusterd-utils.c:23:
In function ‘strncat’,
    inlined from ‘glusterd_add_peers_to_auth_list’ at glusterd-utils.c:14997:27:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:135:10: warning: ‘strncat’ specified bound depends on the length of the source argument [-Wstringop-overflow=]
  135 | return __builtin___strncat_chk (__dest, __src, __len,
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  136 | __glibc_objsize (__dest));
      | ~~~~~~~~~~~~~~~~~~~~~~~~~

- http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=glusterfs
Plenty of vulnerabilities, but the most recent affected version is 4.1.4. Bionic ships 3.13.2, and focal has 7.2 already. Jammy is on 10.0 (proposed)

- site:www.openwall.com/lists/oss-security glusterfs
Previously mentioned CVEs
No hits more recent than 2018. One from 2020, but about kube-controller-manager, which can affect storage volume types and glusterfs is in the list.

- https://ubuntu.com/security/cve?q=glusterfs&package=&priority=&version=&status=
Plenty of CVEs, but note that from Focal onwards we are not affected

- https://github.com/gluster/glusterdocs/security
Unclear if this is used. The advisories tab is empty.

In general, it looks like that was a good shift to having a more secure product, when compared to older versions, at least in terms of CVEs and advisories.

- no `suid` or `sgid` binaries
- plenty of executables in `/sbin` and `/usr/sbin`
- Package installs services:
-rw-r--r-- 1 root root 604 Nov 25 13:38 /lib/systemd/system/glusterd.service
-rw-r--r-- 1 root root 416 Nov 25 13:38 /lib/systemd/system/glustereventsd.service

glusterd runs as root and opens port 24007/tcp:
root 650 0.0 0.8 463484 16948 ? SLsl 13:07 0:00 /usr/sbin/glusterd -p /var/run/glusterd.pid --log-level INFO

glusterfsd runs as root, and has port 51886/tcp open in the port list further below, but no dedicated service file for it. It must be spawned on demand:
root 879 0.0 0.9 678344 18976 ? SLsl 13:07 0:00 /usr/sbin/glusterfsd -s j3-gluster --volfile-id gv0.j3-gluster.data-brick1-gv0 -p /var/run/gluster/vols/gv0/j3-gluster-data-brick1-gv0.pid -S /var/run/gluster/151590e8a4cfce4e.socket --brick-name /data/brick1/gv0 -l /var/log/glusterfs/bricks/data-brick1-gv0.log --xlator-option *-posix.glusterd-uuid=039bb0cb-e8ae-4109-80c4-1680c0900046 --process-name brick --brick-port 51886 --xlator-option gv0-server.listen-port=51886

glusterfs runs as root.
On the server:
root 890 0.0 0.6 597576 13564 ? SLsl 13:07 0:00 /usr/sbin/glusterfs -s localhost --volfile-id shd/gv0 -p /var/run/gluster/shd/gv0/gv0-shd.pid -l /var/log/glusterfs/glustershd.log -S /var/run/gluster/ee6b53133c702918.socket --xlator-option *replicate*.node-uuid=039bb0cb-e8ae-4109-80c4-1680c0900046 --process-name glustershd --client-pid=-6

On a client with a volume mounted:
root 47453 0.0 0.9 649100 18400 ? SLsl 12:58 0:00 /usr/sbin/glusterfs --process-name fuse --volfile-server=j1-gluster --volfile-id=/gv0 /mnt

- Package does not open privileged ports (ports < 1024)
On a server peered with two other servers, and one connected client:
$ sudo netstat -anp|grep gluster|grep -v ^unix
tcp 0 0 0.0.0.0:24007 0.0.0.0:* LISTEN 650/glusterd
tcp 0 0 0.0.0.0:51886 0.0.0.0:* LISTEN 879/glusterfsd
tcp 0 0 192.168.122.32:49150 192.168.122.156:24007 ESTABLISHED 650/glusterd
tcp 0 0 192.168.122.32:51886 192.168.122.157:49147 ESTABLISHED 879/glusterfsd
tcp 0 0 192.168.122.32:49145 192.168.122.156:54119 ESTABLISHED 890/glusterfs
tcp 0 0 192.168.122.32:24007 192.168.122.211:49147 ESTABLISHED 650/glusterd
tcp 0 0 127.0.0.1:24007 127.0.0.1:49148 ESTABLISHED 650/glusterd
tcp 0 0 192.168.122.32:24007 192.168.122.156:49150 ESTABLISHED 650/glusterd
tcp 0 0 127.0.0.1:49148 127.0.0.1:24007 ESTABLISHED 890/glusterfs
tcp 0 0 192.168.122.32:24007 192.168.122.32:49149 ESTABLISHED 650/glusterd
tcp 0 0 192.168.122.32:49148 192.168.122.211:55591 ESTABLISHED 890/glusterfs
tcp 0 0 192.168.122.32:49142 192.168.122.32:51886 ESTABLISHED 890/glusterfs
tcp 0 0 192.168.122.32:51886 192.168.122.32:49142 ESTABLISHED 879/glusterfsd
tcp 0 0 192.168.122.32:49149 192.168.122.32:24007 ESTABLISHED 879/glusterfsd
tcp 0 0 192.168.122.32:51886 192.168.122.156:49145 ESTABLISHED 879/glusterfsd
tcp 0 0 192.168.122.32:51886 192.168.122.211:49145 ESTABLISHED 879/glusterfsd
tcp 0 0 192.168.122.32:49151 192.168.122.211:24007 ESTABLISHED 650/glusterd

There are no listening ports on a client, just the ones opened by the connection(s) established to the server.

- Packages does not contain extensions to security-sensitive software
  (filters, scanners, plugins, UI skins, ...)
This is a networked filesystem, I'd say it's security sensitive.
There are integration points with other packages, like samba (https://wiki.samba.org/index.php/GlusterFS) and libvirt (https://libvirt.org/storage.html#StorageBackendGluster), and of course qemu itself.

[Quality assurance - function/usage]
- After installing the package it must be possible to make it working with
  a reasonable effort of configuration and documentation reading.
The package needs post install configuration or reading of documentation, there isn't a safe default because you need to configure how you want your storage to be used.
There is an easy quickstart page provided by upstream at https://docs.gluster.org/en/latest/Quick-Start-Guide/Quickstart/ that works very well and is an excellent starting point. The instructions use `yum` to install the package, but it's the same package name in Ubuntu and `apt` can be used interchangeably. Same for the systemd service units.

[Quality assurance - maintenance]
The package is maintained well in Debian/Ubuntu and has not too many and long term critical bugs open

Ubuntu bugs:
https://bugs.launchpad.net/ubuntu/+source/glusterfs
- memory leak claims on older versions (3.13.x, 2.20)
- remaining bugs against much older versions of both the package and ubuntu
These bugs should be triaged, and the ones against EOL releases should be closed

Debian bugs:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=glusterfs
Just some that we (Canonical) filed recently, I'm a bit surprised.

Upstream issues:
https://github.com/gluster/glusterfs/issues
- very active, and many bugs to improve the code, like replacing of functions or getting rid of warnings
- Many open pull requests: https://github.com/gluster/glusterfs/pulls , many with test failures showing good CI/CD practice

Release cadence:
Good documented release cadence: https://www.gluster.org/release-schedule/

- The package does not deal with exotic hardware we cannot support

[Quality assurance - testing]
The package does not run a test at build time because who knows.
I found remnants of unit test infrastructure, and there is a makefile target "make check-TESTS", but there are zero tests to run.
I asked about this in the upstream slack channel: https://gluster.slack.com/archives/CHVRH5D50/p1638906018050000
"""
hi everyone, quick (I hope) question, I'm going over requirements to bring the gluster package into ubuntu main (it's in universe), and one of the questions that I have to answer is if there are build-time tests. I've seen the "make check" target, and it prints some output, but always with a zero test count. It's like the test infrastructure is there, but there are no tests. Is that accurate?
1 reply
Amar Tumballi (kadalu.io) 1 day ago
We don't run any tests when making the build (ie, no make test or make check like infra). All tests are run as part of PR review part, and nightly.
"""

They have a collection of jeknins jobs defined here: https://github.com/gluster/build-jobs

They have system tests, but I didn't get them to run out of the box yet. Maybe once working, these could be used as DEP8 tests, if they prove to be reliable enough.
Other than that, without upstream's help, I don't think we can add build-time tests.

Upstream does have tests that run on each branch before it's merged:
https://github.com/gluster/glusterfs/pulls

The package does not run an autopkgtest.
It shouldn't be hard to add some simple yet good enough DEP8 tests, as the server and client portions can be on the same machine. Maybe even a container, since it's a FUSE filesystem (TBD).

[Quality assurance - packaging]
debian/watch is present and works

This package does not yield massive lintian Warnings, Errors
$ lintian --pedantic -I 2>&1 | tee ../lintian.log
E: glusterfs changes: bad-distribution-in-changes-file jammy
W: glusterfs source: newer-standards-version 4.6.0 (current is 4.5.1)
I: glusterfs source: unused-override very-long-line-length-in-source-file configure *
I: glusterfs source: unused-override very-long-line-length-in-source-file doc/gluster.8 *
I: glusterfs source: unused-override very-long-line-length-in-source-file extras/glusterfs-mode.el *
I: glusterfs source: unused-override very-long-line-length-in-source-file xlators/features/changelog/lib/src/Makefile.in *
I: glusterfs-common: unused-override library-not-linked-against-libc usr/lib/*/glusterfs/*/xlator/mount/api.so
N: 15 hints overridden (1 warning, 14 info); 5 unused overrides

Debian report: https://lintian.debian.org/sources/glusterfs

Lintian overrides are present. Notable ones are:
- executable-in-usr-lib (https://lintian.debian.org/tags/executable-in-usr-lib?version=2.113.26) for lots of scripts and other executables. The override file has no explanation. d/changelog is full of the generic expression "adjust lintian overrides" in many uploads.
- no-symbols-control-file (https://lintian.debian.org/tags/no-symbols-control-file). My guess is these shared libraries are not used externally, and just by glusterfs itself. That being said, there is no symbol file at all in this package, and we do have external packages using gluster. I checked the rdeps of libglusterd0 and libglusterfs0, and found one external package linking to libglusterfs0: nfs-ganesha-gluster (in Ubuntu: debian might have more).

This package does not rely on obsolete or about to be demoted packages.
This package has no python2 or GTK2 dependencies
The package will not be installed by default

Packaging and build is easy, link to d/rules: https://git.launchpad.net/ubuntu/+source/glusterfs/tree/debian/rules

[UI standards]
The server itself is not necessarily end-user facing, but client tools are. That being said, administrators would use them, and not really an end-user, if I understand this point correctly.
In cany case, there are no translations for this package.

[Dependencies]
No further depends or recommends dependencies that are not yet in main
Note that firewalld (universe) is a build-dep, and enabled in ./configure, but all that does is install a firewalld xml file defining the glusterfs services. It does NOT pull in firewalld.

[Standards compliance]
This package correctly follows FHS and Debian Policy.
Maybe the biggest violation is executables in usr/lib, instead of /usr/libexec, but even that is flagged as "pedantic" by lintian.

The security team might want to know why this one was overriden:
O: glusterfs-common: hardening-no-fortify-functions usr/lib/x86_64-linux-gnu/glusterfs/10.0/xlator/features/cloudsync.so
d/changelog has this entry about it, from 2016:
  * Adjust false positive lintian overrides for hardening-no-fortify-functions.

[Maintenance/Owner]
Owning Team will be ubuntu-server
Team is not yet subscribed, but will subscribe to the package before promotion

This does not use static builds

[Background information]
The Package description explains the package well
Upstream Name is glusterfs
Link to upstream project https://www.gluster.org/ and https://github.com/gluster/glusterfs

[Andreas Hasenack (ahasenack)]

I'm adding a DEP8 test to glusterfs here: https://bugs.launchpad.net/ubuntu/+source/glusterfs/+bug/1954452

[Lukas Märdian (slyon)]

Review for Package: src:glusterfs

[Summary]
This is a big piece of software and might have quite some security implications
(embedded sources, root daemon, regex parsing, lintian warnings,
openssl3 warnings, ...) but I'll leave this to the security-team to judge on.
It is really unfortunate that it does not currently contain any automated
testing. Thanks for starting the work on a DEP-8 test already, we absolutely
need this! In addition it should be further investigated if the unit-tests can
be run at build time or if we can setup similar test as the upstream CI that
run during build. Having unit tests + DEP-8 would make me feel much more
confortable in ACKing this, but I guess having at least one of them is the bare
minimum.

MIR team ACK under the constraint to resolve the below listed
required TODOs and as much as possible having a look at the
recommended TODOs.

This does need a security review, so I'll assign ubuntu-security

List of specific binary packages to be promoted to main:
glusterfs-cli, glusterfs-client, glusterfs-common, glusterfs-server, libgfapi0,
libgfchangelog0, libgfrpc0, libgfxdr0, libglusterd0, libglusterfs-dev,
libglusterfs0
Specific binary packages built, but NOT to be promoted to main: <none>

Required TODOs:
- Implement & upload the proposed autopkgtests (+ try to get them into Debian):
  Thanks for starting the work on this already!
  https://bugs.launchpad.net/ubuntu/+source/glusterfs/+bug/1954452
- State a plan of how you will stay on top of the embedded sources (security
  issues, updates, ...)

Recommended TODOs:
- The package should get a team bug subscriber before being promoted
- try to enable the unittests (BUILD_UNITTEST="no" in configure.ac) at buildtime
- Work with upstream to resolve the build time warnings
- Work with Debian to clean up the lintian warnings & overrides

[Duplication]
There is no other package in main providing the same functionality.
There are some parallels to Ceph, as a scale-out storage solution, but the
usecases are quite a bit different (object storage in a full cloud environment
vs HA file storage), so I'm not considering this a duplication of functionality.

[Dependencies]
OK:
- no other Dependencies to MIR due to this
  - checked with check-mir
  - not listed in seeded-in-ubuntu
  - none of the (potentially auto-generated) dependencies (Depends
     and Recommends) that are present after build are not in main
- no -dev/-debug/-doc packages that need exclusion
- No dependencies in main that are only superficially tested requiring
  more tests now.

Problems: None

[Embedded sources and static linking]
OK:
- no static linking
- does not have odd Built-Using entries
- not a go package, no extra constraints to consider in that regard

Problems:
- Some embedded sources present (like xxhash, libexecinfo, ...) in contrib/

[Security]
OK:
- history of CVEs does not look concerning (there are plenty of CVEs, but the
  situation seems to have become much better since 2018, only one CVE in 2019
  since then)
- does not use webkit1,2
- does not use lib*v8 directly
- does not process arbitrary web content
- does not use centralized online accounts
- does not integrate arbitrary javascript ...

[Andreas Hasenack (ahasenack)]

A DEP8 test was added and uploaded to jammy, and it migrated already.

[Andreas Hasenack (ahasenack)]

Debian adopted the dep8 test, and the package is in sync again.

[Christian Ehrhardt  (paelzer)]

Thereby the required TODOs are done AFAICS.
Feel free to add more of the recommended steps,
but until then this is New@ubuntu-security as it is waiting for the review.

[Andreas Hasenack (ahasenack)]

> - State a plan of how you will stay on top of the embedded sources (security
> issues, updates, ...)

I'll do this analysis in parallel

[Andreas Hasenack (ahasenack)]

I did some investigation in all of the contrib/ directories:

[Embedded Sources]

[contrib/xxhash]
- https://github.com/Cyan4973/xxHash
- devel ML thread discussing its inclusion: http://lists.gluster.org/pipermail/gluster-devel/2017-June/053173.html
- mailing list thread said back then the linux distros didn't have xxhash packaged. We have it since bionic (so 2018)
- it claims the usage is not cryptographic
- we have it in ubuntu main (https://launchpad.net/ubuntu/+source/xxhash)
- version in jammy is 0.8.0, upstream is 0.8.1
- embedded version in glusterfs is 0.6.5, from April 2018 (https://github.com/Cyan4973/xxHash/releases/tag/v0.6.5)
- pinged upstream about it in slack (https://gluster.slack.com/archives/CHVRH5D50/p1641316163090300)
- -I xxhash.h includes the .c file too, inline:
#if defined(XXH_INLINE_ALL) || defined(XXH_PRIVATE_API)
# include "xxhash.c" /* include xxhash function bodies as `static`, for inlining */
#endif

[contrib/umountd]
- not used on linux

[contrib/userspace-rcu]
- only used if the system has an old liburcu (<= 0.7). Ubuntu jammy has 0.8
PKG_CHECK_MODULES([URCU_CDS], [liburcu-cds >= 0.8], [],
  [PKG_CHECK_MODULES([URCU_CDS], [liburcu-cds >= 0.7],
    [AC_DEFINE(URCU_OLD, 1, [Define if liburcu 0.6 or 0.7 is found])
     USE_CONTRIB_URCU='yes'],
    [AC_CHECK_HEADERS([urcu/cds.h],
      [AC_DEFINE(URCU_OLD, 1, [Define if liburcu 0.6 or 0.7 is found])
       URCU_CDS_LIBS='-lurcu-cds'
       USE_CONTRIB_URCU='yes'],
      [AC_MSG_ERROR([liburcu-cds not found])])])])

And we get in config.h after a build:
$ grep URCU_OLD config.h -B1
/* Define if liburcu 0.6 or 0.7 is found */
/* #undef URCU_OLD */

That being said, the build command lines still pass "-I../../../../contrib/userspace-rcu" regardless

[contrib/timer-wheel]
- seems to have come from the linux kernel: linux/kernel/timer.c and others

[contrib/rbtree]
- comes from http://savannah.gnu.org/projects/avl
- version 2.0.3, last updated in 2007

[mount/]
- not used in linux: #if !defined(GF_LINUX_HOST_OS)

[contrib/macfuse]
- only used in macos/darwing

[contrib/libgen]
- basename_r.c: copied from glibc-2.12.1/string/basename.c, with modifications
- dirname_r.c: copied from glibc-2.12.1/string/memrchr.c and glibc-2.12.1/misc/dirname.c, with modifications

[contrib/libexecinfo]
- not used, because we define HAVE_BACKTRACE:
$ grep HAVE_BACKTRACE config.h -B1
/* define if found backtrace */
#define HAVE_BACKTRACE 1

And:
$ grep HAVE_BACKTRACE contrib/libexecinfo/*
contrib/libexecinfo/execinfo.c:#ifndef HAVE_BACKTRACE
contrib/libexecinfo/execinfo_compat.h:#ifndef HAVE_BACKTRACE

[contrib/fuse-util]
- builds fusermount
- system's fusermount is suid root, and comes from the `fuse` package
- there is a configure option to use the system's fusermount, disabling this built-in copy, but it's not used in the packaging,

[contrib/fuse-lib]
- file has origin declaration and list of changes:
 * These functions (and gf_fuse_umount() in mount.c)
 * were originally taken from libfuse as of commit 7960e99e
 * (http://fuse.git.sourceforge.net/git/gitweb.cgi?p=fuse/fuse;a=commit;h=7960e99e)
 * almost verbatim. What has been changed upon adoption:
...

[contrib/fuse-include]
...

[Christian Ehrhardt  (paelzer)]

On Tue, Jan 4, 2022 at 9:25 PM Andreas Hasenack
<email address hidden> wrote:
>
> I did some investigation in all of the contrib/ directories:

Thanks for that investigation, it seems most of them are unused or
really only a minor concern.
The two more interesting according to your analysis IMHO are xxhash and fuse.

We have libfuse3-3 in main (and fuse3 can follow once depended on,
currently as you
know there is a fuse2->fuse3 move).
Also libxxhash0 is in main since Hirsute.
So going forward if we can make glusterfs use those two from the
system that would
clearly eliminate the biggest chunks of embedded code concerns I'd think.

I'm not sure this works, I'm saying those two seem to be good
candidates to have a deeper look at.

[Andreas Hasenack (ahasenack)]

I'll file an upstream bug asking if they can switch to the upstream xxhash, and experiment a bit with building the glusterfs package with the option to use the system's fusermount command.

[Andreas Hasenack (ahasenack)]

I filed https://github.com/gluster/glusterfs/issues/3097 for gluster to consider switching to the external xxhash library.

[Andreas Hasenack (ahasenack)]

Here is an explanation about fuse's fusermount vs gluster's: https://github.com/gluster/glusterfs/discussions/2212

"""
Glusterfs cannot use standard fusermount; the choice is either installing and using its own variant, or not facilitate unprivileged mounting.
"""

I didn't yet fully understand the details, I'll have to run some experiments. I have a build without gluster's fusermount.

[Christian Ehrhardt  (paelzer)]

Required for 22.04, setting Critical + Milestone 22.02 (FeatureFreeze)

[Andreas Hasenack (ahasenack)]

Upstream is awesome, they have a PR up for being able to use the system provided lib xxhash instead of the bundled one, if one is found on the system: https://github.com/gluster/glusterfs/pull/3127

[Andreas Hasenack (ahasenack)]

I clarified a bit my understsanding of how glusterfs is using fuse. Long comment below.

TL;DR
gluster uses its own copy of fuse for both the fuse xlator, and the fusermount tool (called fusermount-glusterfs). It won't use fuse's fusermount. This also means the depdendencies on libfuse-dev (build) and fuse (runtime) could be dropped.

There are two aspects to this: fusermount-glusterfs, and the fuse xlator mount module.

/usr/bin/fusermount-glusterfs is used when an unprivileged user tries a mount:

  I [mount.c:496:gf_fuse_mount] 0-glusterfs-fuse: direct mount failed (Operation not permitted) errno 1
  I [mount.c:501:gf_fuse_mount] 0-glusterfs-fuse: retry to mount via fusermount

For this to work, two conditions need to be met:
a) the gluster provided /usr/bin/fusermount-glusterfs binary must be built and used (the fuse provided one is ignored)
b) it must be installed SUID root, just like fuse's /usr/bin/fusermount

If a privileged user is doing the mount, then gluster uses a direct mount and fusermount-glusterfs is not used.

Can we then perhaps disable gluster's fusermount, and use the one provided by fuse (/usr/bin/fusermount), which is installed suid root already? No. gluster will not even attempt to use the fuse fusermount command. This then goes down to technical differences between fuse's and gluster's fusermount, some of which are explained in https://github.com/gluster/glusterfs/discussions/2212

The Debian and Ubuntu packaging, as is, do not allow unprivileged mounts, because they ship /usr/bin/fusermount-glusterfs without the SUID root bit set. It might have been a conscious decision, letting the sysadmin decide if they want to enable that bit or not, and keep it during upgrades. Or it's a bug. In any case, they way it is shipped, we could be using --disable-fusermount and would see no difference in behavior.

But gluster still uses fuse.

On to the second point.

Both the fusermount-glusterfs binary, and the fuse xlator, use embedded copies of fuse, in the contrib/ directory. They are not full copies, just enough to build what is needed.

This also means that there is no need for the libfuse-dev build-dependency on the package, and there is also no need for the `fuse` Depends. I built the glusterfs packages with this patch applied, and no fuse packages installed on the system whatsoever:
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,6 @@ Section: admin
 Priority: optional
 Maintainer: Patrick Matthäi <email address hidden>
 Build-Depends: debhelper-compat (= 13),
- libfuse-dev <!nocheck>,
  libibverbs-dev <!nocheck>,
  libdb-dev <!nocheck>,
  librdmacm-dev <!nocheck>,
@@ -37,7 +36,6 @@ Multi-Arch: foreign
 Depends: ${misc:Depends},
  ${shlibs:Depends},
  ${python3:Depends},
- fuse,
  glusterfs-common (>= ${binary:Version})
 Description: clustered file-system (client package)
  GlusterFS is a clustered file-system capable of scaling to several

It built just fine:
$ dpkg --contents ../glusterfs-client_10.0-2ubuntu1~ppa1_amd64.deb |grep fuse
-rwxr-xr-x root/root 35048 2022-01-13 20:42 ./usr/bin/fusermount-glusterfs
lrwxrwxrwx root/root 0 2022-01-13 20:42 ./usr/share/man/man8/fusermount-glusterfs.8.gz -> mount.gl...

[Andreas Hasenack (ahasenack)]

I filed an issue asking upstream to consider using the system provided fuse libraries: https://github.com/gluster/glusterfs/issues/3145

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Andreas Hasenack (ahasenack)]

An update on this MIR, we might have to drop the armhf builds, see https://github.com/gluster/glusterfs/issues/2979#issuecomment-1036057298

[Steve Beattie (sbeattie)]

I'm working on the Security review of GlusterFS, which I have not quite completed, but to offer a comment on fusermount-glusterfs binary, the Security team would strongly prefer to not have another setuid binary for this; the original setuid fusermount has had its own security history and we would not like to see a forked version that has unknown tracking of vulnerabilities, especially for something that upstream considers to be a non-standard usage.

[Andreas Hasenack (ahasenack)]

I agree, and the current packaging is like this. fusermount-glusterfs is not suid root.

[Christian Ehrhardt  (paelzer)]

Just to state it also here and not just in meetings and calls, this is urgent and important for Jammy, so as much asap as you can manage to complete this is appreciated :-)

[Steve Beattie (sbeattie)]

I reviewed glusterfs 10.1-1 as checked into jammy. This
shouldn't be considered a full audit but rather a quick gauge
of maintainability.

GlusterFS is a clustered network file-system.

- CVE History: 27 CVEs, though the most recent are from
  2018. Issue resolution looks okay. One or two of the later
  CVEs were incomplete fixes for earlier issues.
- Build-Depends on openssl, libtirpc, libxml2, rdma libs.
- Several pre/post inst/rm scripts, dedicated to managing the
  systemd services, adding/removing a dedicated gluster user,
  ensuring an initial config file is created, and dealing with
  compiled python files. Most are generated by debhelper tools
  and look okay.
- No init scripts.
- The glusterfs-server package includes to systemd units, to
  manage the primary GlusterFS daemon and the gluster events
  notifier service. The GlusterFS daemon does depend on rpcbind
  services being enabled/started.

  (The upstream source includes a couple more systemd unit
  files that are not included in any of the binary packages.)
- No dbus services.
- No setuid binaries; however, see Andreas' discussion on the
  fusermount-glusterfs binary. In general, the security team
  would STRONGLY prefer to not have another setuid binary,
  especially for what upstream considers a non-standard use
  case and for one that is a modified version of an existing
  binary that has had its own history of security problems.
- There are several binaries in PATH, mostly as one would
  expect (the service daemon itself, mount utilities, the
  events daemon, and some other specialized utilities.
- No sudo fragments.
- No polkit files.
- No udev rules.
- Tests:
  - it has one basic autopkgtest, a smoke test that creates
    and writes to a mountpoint.
  - As Andreas noted, there is an unused semblance of
    unittest infrastructure. There is a wholly unused tests/
    subdirectory. It's great that upstream gates on tests
    passing, but does nothing for us for testing updates/patches
    we might apply. That's not great.
- No cron jobs.
- As noted, build logs contain some warnings, some of
  them somewhat concerning highlighting where string copy
  operations are performed with a bounds limiter based on the
  length of the source of the copy rather than the size of the
  target. Cursory looks indicate that they may not be an issue,
  and there has been some effort to fix these sorts of things
  in the upstream github.

  There's a couple of warnings about not checking the result
  of calls to setreuid() in contrib/fuse-lib/mount-common.c:59
  which just emphasizes again that it would be best to not
  make the fusermount-glusterfs setuid.

  Nothing concerning in the lintian warnings, though that the
  warning of a lack of symbols tracking in the libraries has
  been silenced is not a great look. (The upstream libraries
  export a defined set of symbols, but don't make use of symbol
  versioning, either.)

- Processes are spawned in a few locations, but look to be
  handled safely (outside of testcases).
- Lots of fiddly memory management happening, memcpys,
  strcpys, etc.
- File IO is okay.
- Logging is complex but okay.
- Minimal use of environment variables, mostly for
...

[Christian Ehrhardt  (paelzer)]

Now all is in place, but due to all the delay this is now much later than intended.
We will prepare the changes to samba and qemu which will pull this in, but given the time I'd feel more comfortable to have a quick release-team FFE-ack.

PPAs:
- qemu: https://launchpad.net/~paelzer/+archive/ubuntu/lp-1246924-enable-glusterfs
- samba: https://launchpad.net/~ahasenack/+archive/ubuntu/samba-gluster-mir/+packages

MRs:
- qemu: https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/418926
- samba: https://code.launchpad.net/~ahasenack/ubuntu/+source/samba/+git/samba/+ref/jammy-samba-gluster-mir

P.S. From the MIR process all info is here already not more needed for an FFE look at this.

[Łukasz Zemczak (sil2100)]

I would be fine on the MIR part, but I feel like I don't have enough context and understanding to make a call on the required deltas in samba and qemu, since it's so late in the cycle. Could you give me an overview of your suspected regression potential of enabling gluterfs in both qemu and samba? I suppose this was always enabled in Debian?

[Christian Ehrhardt  (paelzer)]

Hi Łukasz,
thanks for having a look - sure let me try to summarize an answer to your question.

# General

Yes - Debian has this enabled in both for what feels like ages.
It was the supportability in main which blocked us from following that, but we had plenty of requests and are happy to finally do so.

# qemu

This support has only effect if you call qemu with it enabled, that would be:
--drive file=gluster...
driver":"qcow2","file":{"driver":"gluster",
...

The important thing here is that so far this never worked, it would just tell you "Unknown protocol 'gluster'", but if not enabled it won't be used -> no regression for existing cases.

Not even the .so file will be loaded without calling it on the commandline:
$ strace -rtf -o q.strace qemu-system-x86_64
$ grep gluster.so q.strace
$ strace -rtf -o qg.strace qemu-system-x86_64 --drive file=gluster://192.0.2.1/testvol/a.img
$ grep gluster.so qg.strace
43900 12:49:01 (+ 0.000258) access("/usr/lib/x86_64-linux-gnu/qemu/block-gluster.so", F_OK) = 0
43900 12:49:01 (+ 0.000097) newfstatat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/qemu/block-gluster.so", {st_mode=S_IFREG|0644, st_size=39240, ...}, 0) = 0
43900 12:49:01 (+ 0.000103) openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/qemu/block-gluster.so", O_RDONLY|O_CLOEXEC) = 3

Furthermore it is packaged in qemu-block-extra which is only a recommends. So someone that wants not even a bit to be present can remove that (also includes other less common block drivers like isci, ceph, ...)

# samba

Here it also is packaged separately in samba-vfs-modules which contains various optional samba extra features. People scared of gluster or any else can remove it.

Also does is it only active if configured in the samba config.
Details are here: https://www.samba.org/samba/docs/current/man-html/vfs_glusterfs.8.html
The TL;DR is (again as with qemu) that former users can't have it enabled yet (it would have failed always) and new users still need to enable it so that anything happens.

[Andreas Hasenack (ahasenack)]

This is the samba bug requesting glusterfs support: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1894618

I suppose that should be an FFe now?

The diff in the samba package is shown in this MP I just filed: https://code.launchpad.net/~ahasenack/ubuntu/+source/samba/+git/samba/+merge/419134

[Christian Ehrhardt  (paelzer)]

Thanks for linking that Andreas.
For qemu it is: https://bugs.launchpad.net/cloud-archive/+bug/1246924

I think the FFE decision is the same for both samba/qemu and the reason to come by late the same as well (this MIR being stalled) - so I'd hope it makes it more easy to think->decide about it once, just here on this bug.

[Andreas Hasenack (ahasenack)]

This is the diff in the samba-vfs-modules package contents:
$ diff -u samba-vfs-modules-gluster-in-universe.list samba-vfs-modules-gluster-in-main.list
--- samba-vfs-modules-gluster-in-universe.list 2022-04-08 14:14:23.928484249 -0300
+++ samba-vfs-modules-gluster-in-main.list 2022-04-08 14:14:18.384347772 -0300
@@ -26,6 +26,7 @@
 /usr/lib/x86_64-linux-gnu/samba/vfs/fruit.so
 /usr/lib/x86_64-linux-gnu/samba/vfs/full_audit.so
 /usr/lib/x86_64-linux-gnu/samba/vfs/glusterfs_fuse.so
+/usr/lib/x86_64-linux-gnu/samba/vfs/glusterfs.so
 /usr/lib/x86_64-linux-gnu/samba/vfs/gpfs.so
 /usr/lib/x86_64-linux-gnu/samba/vfs/io_uring.so
 /usr/lib/x86_64-linux-gnu/samba/vfs/linux_xfs_sgid.so
@@ -80,6 +81,7 @@
 /usr/share/man/man8/vfs_fileid.8.gz
 /usr/share/man/man8/vfs_fruit.8.gz
 /usr/share/man/man8/vfs_full_audit.8.gz
+/usr/share/man/man8/vfs_glusterfs.8.gz
 /usr/share/man/man8/vfs_glusterfs_fuse.8.gz
 /usr/share/man/man8/vfs_gpfs.8.gz
 /usr/share/man/man8/vfs_io_uring.8.gz

And in its metadata:
--- samba-vfs-modules-gluster-in-universe.metadata 2022-04-08 14:16:17.639099176 -0300
+++ samba-vfs-modules-gluster-in-main.metadata 2022-04-08 14:15:57.318656033 -0300
@@ -2,15 +2,15 @@
 Status: install ok installed
 Priority: optional
 Section: net
-Installed-Size: 1846
+Installed-Size: 1904
 Maintainer: Ubuntu Developers <email address hidden>
 Architecture: amd64
 Multi-Arch: same
 Source: samba
-Version: 2:4.15.5~dfsg-0ubuntu4
+Version: 2:4.15.5~dfsg-0ubuntu5~ppa1
 Replaces: samba (<< 2:4.3.2+dfsg-1), samba-libs (<< 2:4.3.2+dfsg-1)
-Depends: samba-libs (= 2:4.15.5~dfsg-0ubuntu4), libbsd0 (>= 0.0), libc6 (>= 2.33), libgnutls30 (>= 3.7.0), libtalloc2 (>= 2.3.3~), libtdb1 (>= 1.4.4~), libtevent0 (>= 0.11.0~), libtirpc3 (>= 1.0.2), liburing2 (>= 2.0), libwbclient0 (= 2:4.15.5~dfsg-0ubuntu4)
-Recommends: libcephfs2 (>= 12.0.3), libdbus-1-3 (>= 1.9.14)
+Depends: samba-libs (= 2:4.15.5~dfsg-0ubuntu5~ppa1), libbsd0 (>= 0.0), libc6 (>= 2.33), libgnutls30 (>= 3.7.0), libtalloc2 (>= 2.3.3~), libtdb1 (>= 1.4.4~), libtevent0 (>= 0.11.0~), libtirpc3 (>= 1.0.2), liburing2 (>= 2.0), libwbclient0 (= 2:4.15.5~dfsg-0ubuntu5~ppa1)
+Recommends: libcephfs2 (>= 12.0.3), libdbus-1-3 (>= 1.9.14), libgfapi0 (>= 10.1)
 Breaks: samba (<< 2:4.3.2+dfsg-1), samba-libs (<< 2:4.3.2+dfsg-1)
 Enhances: samba
 Description: Samba Virtual FileSystem plugins
@@ -28,7 +28,7 @@
   * vfs_shadow_copy2: Expose snapshots to Windows clients as shadow copies
   * vfs_worm: Disallow writes for older file
  .
- Note: The runtime dependencies of vfs_ceph and vfs_snapper are moved to
- Recommends.
+ Note: The runtime dependencies of vfs_ceph, vfs_glusterfs and vfs_snapper are
+ moved to Recommends.
 Homepage: http://www.samba.org
 Original-Maintainer: Debian Samba Maintainers <email address hidden>

[Steve Langasek (vorlon)]

AIUI this is just enabling an additional optional stand-alone module, which is not used by default. So, FFe ack for samba.

[Steve Langasek (vorlon)]

Same for qemu, the only runtime impact is the availability of an opt-in feature. Acked.

[Christian Ehrhardt  (paelzer)]

FYI - uploads done, got accepted a few hours ago and building now.
Also the team subscription to the package was done.

It shows in component mismatches:
glusterfs: libgfapi0 libgfrpc0 libgfxdr0 libglusterfs0
  MIR: #1950321 (Confirmed)
  MIR: #1274247 (Won't Fix)
  [Reverse-Depends: libgfapi0, libgfrpc0]
  [Reverse-Recommends: samba-vfs-modules (MAIN)]

We might also want a seed change to pull the client/server binary packages.
@Andreas - I hear you do that, once visible in component mismatches could you update here so that archive admins can promote it?

[Andreas Hasenack (ahasenack)]

Here is the seed change PR:

https://code.launchpad.net/~ahasenack/ubuntu-seeds/+git/platform/+merge/419225

[Andreas Hasenack (ahasenack)]

Seed change merged.

[Andreas Hasenack (ahasenack)]

It's all showing up in component mismatches now (https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed)

[Steve Langasek (vorlon)]

Override component to main
glusterfs 10.1-1 in jammy: universe/admin -> main
glusterfs-cli 10.1-1 in jammy amd64: universe/admin/optional/100% -> main
glusterfs-cli 10.1-1 in jammy arm64: universe/admin/optional/100% -> main
glusterfs-cli 10.1-1 in jammy armhf: universe/admin/optional/100% -> main
glusterfs-cli 10.1-1 in jammy ppc64el: universe/admin/optional/100% -> main
glusterfs-cli 10.1-1 in jammy riscv64: universe/admin/optional/100% -> main
glusterfs-cli 10.1-1 in jammy s390x: universe/admin/optional/100% -> main
glusterfs-client 10.1-1 in jammy amd64: universe/admin/optional/100% -> main
glusterfs-client 10.1-1 in jammy arm64: universe/admin/optional/100% -> main
glusterfs-client 10.1-1 in jammy armhf: universe/admin/optional/100% -> main
glusterfs-client 10.1-1 in jammy ppc64el: universe/admin/optional/100% -> main
glusterfs-client 10.1-1 in jammy riscv64: universe/admin/optional/100% -> main
glusterfs-client 10.1-1 in jammy s390x: universe/admin/optional/100% -> main
glusterfs-common 10.1-1 in jammy amd64: universe/libs/optional/100% -> main
glusterfs-common 10.1-1 in jammy arm64: universe/libs/optional/100% -> main
glusterfs-common 10.1-1 in jammy armhf: universe/libs/optional/100% -> main
glusterfs-common 10.1-1 in jammy ppc64el: universe/libs/optional/100% -> main
glusterfs-common 10.1-1 in jammy riscv64: universe/libs/optional/100% -> main
glusterfs-common 10.1-1 in jammy s390x: universe/libs/optional/100% -> main
glusterfs-server 10.1-1 in jammy amd64: universe/admin/optional/100% -> main
glusterfs-server 10.1-1 in jammy arm64: universe/admin/optional/100% -> main
glusterfs-server 10.1-1 in jammy armhf: universe/admin/optional/100% -> main
glusterfs-server 10.1-1 in jammy ppc64el: universe/admin/optional/100% -> main
glusterfs-server 10.1-1 in jammy riscv64: universe/admin/optional/100% -> main
glusterfs-server 10.1-1 in jammy s390x: universe/admin/optional/100% -> main
libgfapi0 10.1-1 in jammy amd64: universe/libs/optional/100% -> main
libgfapi0 10.1-1 in jammy arm64: universe/libs/optional/100% -> main
libgfapi0 10.1-1 in jammy armhf: universe/libs/optional/100% -> main
libgfapi0 10.1-1 in jammy ppc64el: universe/libs/optional/100% -> main
libgfapi0 10.1-1 in jammy riscv64: universe/libs/optional/100% -> main
libgfapi0 10.1-1 in jammy s390x: universe/libs/optional/100% -> main
libgfchangelog0 10.1-1 in jammy amd64: universe/libs/optional/100% -> main
libgfchangelog0 10.1-1 in jammy arm64: universe/libs/optional/100% -> main
libgfchangelog0 10.1-1 in jammy armhf: universe/libs/optional/100% -> main
libgfchangelog0 10.1-1 in jammy ppc64el: universe/libs/optional/100% -> main
libgfchangelog0 10.1-1 in jammy riscv64: universe/libs/optional/100% -> main
libgfchangelog0 10.1-1 in jammy s390x: universe/libs/optional/100% -> main
libgfrpc0 10.1-1 in jammy amd64: universe/libs/optional/100% -> main
libgfrpc0 10.1-1 in jammy arm64: universe/libs/optional/100% -> main
libgfrpc0 10.1-1 in jammy armhf: universe/libs/optional/100% -> main
libgfrpc0 10.1-1 in jammy ppc64el: universe/libs/optional/100% -> main
libgfrpc0 10.1-1 in jammy riscv64: universe/libs/optional/100% -> main
libgfrpc0 10.1-1 in...