[Bug] Vault accepts a value it later refuses to inject, and the audit trail cannot separate refused from absent

Abierto
  • ¿Algo no está bien?
#68 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
52/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
go
Área
authorization, cli, security

Línea de trabajo

Start with the fs-vault create-secret, replace-secret, run-with-secret, read-secret, and list-audit-events command paths, then reproduce both cases from the issue. Check where field values are validated and where delegated reads become audit events. Done means invalid values are refused on write and the audit trail distinguishes denied access to an existing field from a missing field.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

ti version

0.2.7 (6c950c77a601d0d55394c4b2f64483ae93d522db, 2026-09-27), bundled ti-drive9 companion 60b63d6

Command family

fs-vault

Operating system and architecture

macOS 14.6, darwin/arm64, for both problems. Problem 1 was also seen on Ubuntu, linux/amd64.

Summary

One validation problem and one question about the audit trail.

Covers observations 7 and 4 from a review of the TiDB Cloud Filesystem documentation.

Problem 1: a control byte is accepted on write and refused on use

Command
ti fs-vault create-secret --secret-name ctl --field K="$(printf 'ab\001cd')"
ti fs-vault run-with-secret --secret-path /n/vault/ctl -- /bin/sh -c 'echo injected'
Reproduction steps
  1. Create or replace a secret whose field value contains a control byte.
  2. Observe that the command reports success.
  3. Run run-with-secret to inject that field.
Expected behavior

The write is refused, at the moment the value is supplied, naming the offending byte.

Actual behavior

create-secret and replace-secret both accept the value and report success at exit 0.
run-with-secret then refuses to inject it at exit 1:

ti [ERROR]: vault with: secret value for key "K" contains forbidden control byte 0x01 at offset 2

A secret with a clean value runs normally through the same command, which confirms the refusal
is about the stored value rather than the invocation. The secret is stored in a state where it cannot
be used, and the caller only discovers this at the point of use, which may be much later and
in a different place.

Validating at write time would remove the failure entirely. As it stands the documentation has
to warn readers about a value the product accepted without complaint, which is a weaker
remedy.

Problem 2: a delegated read cannot be told apart from a missing field

Command
ti fs-vault create-grant --scope db/DB_URL --permission read --agent-id a1 --ttl 30m --token-only
ti fs-vault read-secret --secret-name db --field PASSWORD --vault-token "<delegated-token>"
ti fs-vault read-secret --secret-name db --field NOPE --vault-token "<delegated-token>"
ti fs-vault list-audit-events --output text
Reproduction steps
  1. Grant a delegated token access to one field of a secret.
  2. Read a different field of that secret with it.
  3. Read a field that does not exist at all.
  4. Compare the messages and the audit entries.
Actual behavior

Both cases return vault get: not found at exit 1, and both record secret.denied in the audit
trail. The granted field reads normally at exit 0.

  DB_URL     exit=0
  PASSWORD   exit=1   vault get: not found
  NOPE       exit=1   vault get: not found

TIME                  AGENT  ACTION          SECRET  FIELD
2026-09-28T03:42:11Z  a1     secret.denied   db      NOPE
2026-09-28T03:42:11Z  a1     secret.denied   db      PASSWORD
2026-09-28T03:42:11Z  a1     secret.read     db      DB_URL

Note that NOPE appears in the FIELD column as though it were a real field of the secret.

Hiding existence from the caller is a common and defensible vault design, so the message may
well be deliberate. The part worth asking about is the audit trail. An auditor reading
secret.denied cannot tell whether someone was refused access to a field that exists or asked
for a field that never existed. Those are different events, and only one of them is worth
investigating.

This is a question rather than a bug report. Please confirm whether the current behaviour is
intended, and if so I will document it as designed.

Sensitive-data confirmation

No API keys, file system or Vault tokens, database credentials, connection strings, SQL, or
customer data appear above. No real secret values are reproduced. File systems used for these
measurements were deleted afterwards.

Lenguaje dominante
Go
Estrellas
3
Forks
4
Merge medio
3 d 19 h
PR fusionados (30 d)
5

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de tidbcloud/ti-cli

Todos los issues de tidbcloud/ti-cli

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.