NFS — rien, sauf Kerberos ou un certificat

serve "nfs" { addr = "0.0.0.0:2049" }

Donc un partage qui nomme qui peut l’utiliser n’est pas exporté en NFS. Le refus est affiché au démarrage et dans check, avec sa raison :

nfs    on 0.0.0.0:2049 — scratch
       photos is not served over nfs: it is restricted to alice and bob, and
       NFSv3 on its own has no authentication: AUTH_UNIX is a claim the client
       makes about itself and the wire cannot disagree with it. A kerberos
       block lifts this: sec=krb5 carries a principal a ticket proves; so
       does identity = "certificate" on the nfs serve block: RPC-over-TLS
       with a client certificate naming the person

Un partage sans allow ni writers — quiconque se connecte, en lecture-écriture — est exporté en NFS, car il n’y a là aucune règle que le protocole pourrait manquer d’honorer.

Le refus qui était autrefois définitif

Un bloc kerberos permet à NFS de distinguer les personnes, et un partage restreint est alors servi par ce biais comme partout ailleurs :

kerberos {
  realm  = "EXAMPLE.ORG"
  keytab = "/etc/fileshare/krb5.keytab"
}

sec=krb5 transporte un principal qu’un ticket prouve, plutôt qu’un uid que le client affirme.

Sur TLS : la machine, pas la personne

serve "nfs" {
  tls            = true
  client_ca_file = "/etc/fileshare/tls/clients.pem"
}

Depuis la v0.9.0, NFS est servi en RPC-with-TLS (RFC 9289) avec tls = true et un bloc tls. Il chiffre ; avec client_ca_file, il oblige un client à présenter un certificat de cette autorité — c’est-à-dire quel hôte monte. L’uid à l’intérieur reste celui qu’affirme AUTH_SYS : un partage restreint est donc toujours refusé par ce biais. TLS est proposé, pas exigé : un client qui ne le demande jamais se voit toujours servir les partages ouverts.

Une personne, d’après son certificat

Depuis la v0.12.0, un certificat peut nommer une personne — tel que go-authn/bridge en émet un après une connexion auprès d’un fournisseur d’identité — et un partage qui nomme des personnes est alors servi en NFS sans kerberos :

serve "nfs" {
  tls            = true
  client_ca_file = "/etc/fileshare/bridge-x509-ca.pem"
  identity       = "certificate"
  crl_url        = "https://bridge.example.org/x509/crl"   # or crl_file: one is required
}

Ce que transporte le certificat, la CRL exigée, et ce qui a été mesuré avec un vrai client Linux (MNT en clair, les pièges de tlshd) se trouvent dans NFS, avec des identités issues de certificats.