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
geo-replication, and is okay.
- Privileged function use oustide of fuse is okay.
- RPC can use tls via libssl, looks okay.
- Use of temp files looks to be safe, though TMPDIR is not
honored.
- As one would expect, significant Use of networking; in
general looks okay.
- No use of WebKit.
- No use of PolicyKit.
- No significant cppcheck issues that were not likely false
positives.
- Coverity reported around 500 issues, but spot checking a few,
they appeared to be false positives or things like failing to
deallocate memory in a command line tool. Upstream appears
to be making fixes based on the public Coverity scanner,
so that's good.
- shellcheck found some issues, including in
xlators/mount/fuse/utils/mount.glusterfs.in which gets
installed as /sbin/mount.glusterfs. Not a direct security
concern and there is at least some effort to address
shellcheck issues upstream.
- No significant bandit results.
Close to 500 TODO/FIXME type comments which is not a great sign.
I investigated the lintian override for the fortify hardening
check, and it does appear to be a false positive that is being
silenced, and thus okay.
In talking with Andreas, I understand the difficulty with trying
to get the upstream tests (in particular those driven by the
run-tests.sh script) working, but I think it still would be
something that would give us far more confidence when performing
updates, security or otherwise. It would also be good to clarify
explicitly why (debian) symbol versioning is not done, or get
it in place. Neither are blockers for acceptance.
Overall, there seems to be a marked improvement focusing on
quality versus the last time this package was submitted for
an MIR.
Security team ACK for promoting glusterfs to main.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1950321
Title:
[MIR] glusterfs
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glusterfs/+bug/1950321/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
