État

Ces pages décrivent fileshare v0.29.1.

Ce que chaque version a ajouté

Vérifié

Ce sont des choses qu’on a fait faire à un client que ce projet n’a pas écrit, et non des affirmations sur le code.

• macOS monte un partage en SMB pendant que curl écrit dans la même image en WebDAV, et relit ce que WebDAV a écrit. L’écriture WebDAV de bob sur un partage qu’il ne peut que lire donne 403 ; un mauvais mot de passe donne 401.
• go-smb2 — un client que ce projet n’a pas écrit — mène vingt lectures concurrentes en SMB pendant que vingt autres passent par WebDAV, sous -race, en CI.
• Les règles d’accès sont vérifiées à travers chaque protocole plutôt que dans la seule configuration : alice écrit et bob non, en SMB comme en WebDAV, et le partage n’est même pas proposé à NFS.
• Les certificats SFTP sont vérifiés face au propre client d’OpenSSH, qui refuse aussi la même clé dès que son certificat est mis de côté.
• Les identités NFS issues de certificats ont été mesurées avec un vrai client Linux (noyau 6.17, ktls-utils 0.9) dans la CI de go-filesystems/nfs — c’est ainsi que MNT en clair et les pièges de tlshd ont été découverts.
• La forme non signée de la KRL est une mesure : OpenSSH 9.6 et 10.3 lisent une KRL signée et ignorent la signature (go-authn/krl, contre les deux).
• La voie d’interopérabilité de go-authn/bridge (#12, #17) juge fileshare v0.13.0 face au vrai bridge : la KRL, la CRL en NFS, les jetons WebDAV révoqués par signaux partagés, un IdP désactivé par portée, et opkssh par signaux partagés.

Pas encore

Les écritures en S3. PUT et DELETE répondent 403. La bibliothèque sait écrire, mais un partage qu’une personne ne peut que lire doit refuser au même endroit que SFTP, et ce n’est pas câblé. Refuser vaut mieux qu’un objet à moitié écrit.

Un jeton OIDC en S3. Les jetons fonctionnent en WebDAV et nulle part ailleurs. La voie habituelle pour S3 est STS AssumeRoleWithWebIdentity, qui échange le jeton contre des identifiants temporaires avec lesquels le client signe ensuite — un mécanisme différent de l’acceptation d’un jeton porteur, et non implémenté.

--isolate avec un bloc admin ou metrics. Refusé : il n’y a aucun processus unique auquel une modification par l’API pourrait s’appliquer. Voir un processus par protocole.

Une personne par utilisateur sur un client NFS Linux partagé, à partir d’un certificat. Un client Linux attache le certificat à un montage : chaque utilisateur du montage est donc la personne qu’il nomme. C’est une propriété du client, et la réponse y est sec=krb5. Voir ce qu’elle ne peut pas promettre.

S3 lui-même est livré : un partage est un bucket, servi sur la même arborescence par utilisateur que celle de SFTP.

Mesuré, et énoncé comme mesuré

Les affirmations de ces pages qui relèvent de l’assurance ou de la mesure plutôt que de la reproduction d’un défaut, et qui sont écrites ainsi dans le source aussi :

• Huit goroutines qui écrivent à travers un pilote fat32 non enveloppé sous -race ne produisent aucune course aujourd’hui. Le verrou partagé est une assurance sur un contrat — go-filesystems/interface ne promet rien sur les appels concurrents par chemin — et non le correctif d’une panne observée.
• Les tailles selon les étiquettes de compilation ont été mesurées, y compris les 13,2 Mo que coûte à lui seul hashicorp/go-plugin, ce qui a tranché contre un cadre de greffons — et les 11,7 Mo que coûte gRPC maintenant que l’API d’administration l’apporte, ce qui explique l’existence de nogrpc.
• Une extension de certificat propre pour les groupes a été conçue et mesurée face à l’analyseur X.509 de Go, qui a refusé le certificat entier ; les groupes voyagent donc sous forme d’URI tag.