On 4 Feb 2022, at 10:17, Chuck Lever III wrote:
Hi Ben-
On Feb 4, 2022, at 7:56 AM, Benjamin Coddington <bcodding@xxxxxxxxxx>
wrote:
The nfs4id program will either create a new UUID from a random source
or
derive it from /etc/machine-id, else it returns a UUID that has
already
been written to /etc/nfs4-id. This small, lightweight tool is
suitable for
execution by systemd-udev in rules to populate the nfs4 client
uniquifier.
Glad to see some progress here!
Regarding the generation of these uniquifiers:
If you have a UUID generation mechanism, why bother with machine-id at
all?
We'd like to deterministically tie our clients to /etc/machine-id for a
number
of reasons:
- it condenses the work of "uniquifying" a machine to a single point
in
the distro.
- the machine-id has a number of ways to handle cases where machines
are
PXE-booted, cloned, or used as "golden images" for cloud containers
(See
machine-id(5)).
- the machine-id has good documentation and awareness (See sd-id128(3)
and
friends)
As noted in bugzilla@redhat 1801326, these uniquifiers will appear in
the
clear on open networks (and we all know open network deployments are
common
for NFS). I don't believe that TLS or GSS Kerberos will be available
to
protect every deployment from a network MitM from sniffing these
values and
attempting to make some hay with them. In particular, any deployment
of a
system before we have in-transit NFS encryption implemented will be
vulnerable.
Yes.
Some young punk from Tatooine could drop a bomb down our reactor
shaft,
and then where would we be?
This little tool isn't attempting to solve any of those problems.
Regarding the storage of these uniquifiers:
As discussed in earlier threads, we believe that storing multiple
unique-ids
in one file, especially without locking to prevent tearing of data in
the
file, is problematic. Now, it might be that the objection to this was
based
on storing these in a file that can simultaneously be edited by humans
(ie, /etc/nfs.conf). But I would prefer to see a separate file used
for
each uniquifier / network namespace.
This tool isn't trying to store uniquifiers for multiple namespaces, or
describe how it ought to be used in relation to namespaces. It only
attempts to create a fairly persistent unique value that can be
generated
and consumed from a udev rule.
I think the problem of how to create uniquifiers for every net namespace
might easily be solved by bind-mounding /etc/nfs4-id into the
namespace-specific filesystem, or a number of other ways. That would be
an
interesting new topic. New sources could be added to this tool in the
future that are namespace-aware.
Thanks for the look at this!
Ben
