Existence checks depend on MinIO error codes; decide policy/user existence from list calls instead

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

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
72/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
go
Lĩnh vực
api, backend

Hướng nghiên cứu

Start in internal/s3/client/impl/minioS3Client.go at GetPolicyInfo, UserExist, and DeleteUser, then read the surrounding MinIO client methods and their callers. Trace the list operations proposed for policies and users, preserving list errors, and verify that missing objects can be created or treated as already deleted without relying on MinIO-specific error codes.

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

Mô tả

Summary

The MinIO client decides whether a policy or user exists by matching MinIO-specific error codes. Any backend that implements the MinIO admin API but reports "not found" differently can never get a Policy or S3User created. Its CRs are requeued indefinitely.

We hit this with RustFS (s3Provider: minio): Bucket CRs reconcile, Policy and S3User never do. The root cause is not RustFS-specific. The client depends on error nomenclature, as the code comment itself notes: "Not ideal (breaks if error nomenclature changes)".

Why this matters now: MinIO community edition is no longer maintained

  • minio/minio, minio/mc and minio/operator are archived on GitHub. The minio/minio README states "THIS REPOSITORY IS NO LONGER MAINTAINED" and points to the proprietary AIStor editions.
  • The images are gone from Docker Hub (minio/minio → 404), and quay.io/minio/minio now requires authentication (401).
  • The last public server image is RELEASE.2025-09-07T16-13-09Z. The fix for CVE-2025-62506 (RELEASE.2025-10-15T17-29-55Z) exists only as source.

Many s3-operator users will move off MinIO to other self-hosted S3 servers. Where the new server implements the MinIO admin API (RustFS does), they can keep s3Provider: minio, but only if the client stops relying on MinIO's exact error nomenclature. Making the existence checks backend-neutral keeps the minio provider useful after MinIO itself is gone.

Where

internal/s3/client/impl/minioS3Client.go (commit 54d5781):

  • GetPolicyInfo (L341): madmin.ToErrorResponse(err).Code == "XMinioAdminNoSuchPolicy"
  • UserExist (L425) and DeleteUser (L440): ... == "XMinioAdminNoSuchUser"

With madmin-go/v4 the HTTP status is not kept in ErrorResponse, so status-based detection isn't an option either.

What a missing object returns (measured with madmin-go/v4 v4.10.0, the version in go.mod):

Call on a missing object MinIO RELEASE.2025-09-07 RustFS 1.0.0
InfoCannedPolicy 404 XMinioAdminNoSuchPolicy 500 InternalError "policy does not exist"
GetUserInfo 404 XMinioAdminNoSuchUser 404 NoSuchResource
RemoveUser 404 XMinioAdminNoSuchUser 500 InternalError "…user '…' does not exist"

The two RustFS 500s are reported upstream in https://github.com/rustfs/rustfs/issues/8117. Even once they are fixed, RustFS's not-found code is NoSuchResource, not XMinioAdmin*.

Proposal: decide existence from list calls, not from error codes (happy to send a PR)

  • PolicyExist(name) → ListCannedPolicies() and look up name. Call InfoCannedPolicy only for policies known to exist.
  • UserExist(accessKey) → ListUsers() and look up accessKey.
  • DeleteUser(accessKey) → remove only if the user is listed; otherwise treat it as already deleted.
  • Any error from the list calls themselves stays a real error.

This removes the dependency on error nomenclature entirely. I checked the same sequence on both backends with madmin-go/v4 v4.10.0:

  • list (absent) → add → list (present) → info → remove → list (absent)

Both ListCannedPolicies and ListUsers reflect creation and removal immediately, on MinIO and on RustFS 1.0.0. This works on RustFS today, including the 500 cases above.

The cost is one list call per reconcile of a Policy / S3User. That is fine for the usual number of identities per instance. A short-lived cache could be added later if needed.

The current code-based checks could stay as a fast path where the code is recognised, with the list call as the fallback. The list is the source of truth either way.

Reproduce

  1. Deploy RustFS 1.0.0.
  2. Create an S3Instance with s3Provider: minio pointing at it.
  3. Apply a Policy and an S3User.
  4. The operator logs an error occurred while checking policy existence / an error occurred when checking user's existence, and requeues indefinitely.

A policy created by hand beforehand does reconcile, and the operator updates it. Only creation (and user deletion) is blocked.

Environment

  • inseefrlab/s3-operator:v0.12.0 (code at main 54d5781 has the same checks)
  • RustFS rustfs/rustfs:1.0.0, on k3d (k3s v1.30); MinIO RELEASE.2025-09-07T16-13-09Z for comparison
Ngôn ngữ chính
Go
Star
66
Fork
16
Không có pull request nào được merge trong 30 ngày

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

Mở trong Codespaces

Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.

  • Có Dockerfile hoặc tệp Docker Compose
  • Không có mẫu pull request
  • Không có hướng dẫn đóng góp

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 InseeFrLab/s3-operator

Tất cả issue của InseeFrLab/s3-operator

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.