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

Đang mở
  • Có gì không ổn?
#68 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
52/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
go
Lĩnh vực
authorization, cli, security

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Go
Star
3
Fork
4
Merge trung bình
3 ngày 19 giờ
Pull request đã merge (30 ngày)
5

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của tidbcloud/ti-cli

Tất cả issue của tidbcloud/ti-cli

Issue tương tự

Thêm issue về Go

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.