br: S3 GetObject permission check ignores configured prefix

[YuJuncen]

Bug Report

1. Minimal reproduce step (Required)

1. Create or use an S3 bucket, for example s3://example-bucket/br-prefix/.

2. Grant BR credentials access only under the configured object prefix. For example, allow object actions such as s3:GetObject, s3:PutObject, and s3:DeleteObject on:

   arn:aws:s3:::example-bucket/br-prefix/*
   

   Also grant the required bucket-level s3:ListBucket permission with a prefix condition for br-prefix/*.

3. Run a BR task that initializes S3 external storage with the same prefix, for example:

   br backup full --storage 's3://example-bucket/br-prefix/?region=<region>'

4. In the current release-8.5 branch, the S3 GetObject permission check uses a hard-coded object key at the bucket root:

   // getObjectCheck checks the permission of getObject
   func getObjectCheck(ctx context.Context, svc S3API, qs *backuppb.S3) error {
       input := &s3.GetObjectInput{
           Bucket: aws.String(qs.Bucket),
           Key:    aws.String("not-exists"),
       }
       _, err := svc.GetObject(ctx, input)
       var aerr smithy.APIError
       if goerrors.As(err, &aerr) {
           if aerr.ErrorCode() == noSuchKey {
               return nil
           }
           return errors.Trace(err)
       }
       return nil
   }

   Because the check probes s3://example-bucket/not-exists instead of a key under s3://example-bucket/br-prefix/, prefix-scoped credentials can fail the permission check even though they have all permissions needed for the configured BR storage path.

2. What did you expect to see? (Required)

BR should validate GetObject permission using an object key under the configured S3 prefix.

For example, the permission check should probe a non-existent key derived from the configured prefix, such as:

br-prefix/perm-check/<uuid>

With credentials that are intentionally limited to the BR prefix, storage initialization should pass as long as the configured prefix has the required permissions.

3. What did you see instead (Required)

BR probes the bucket-root key not-exists.

For prefix-scoped S3 credentials, this can return AccessDenied instead of NoSuchKey, causing BR storage initialization or preflight permission checks to fail before the backup/restore task starts.

The credentials are valid for the configured BR storage prefix, but the permission check uses a key outside that authorized scope.

4. What is your TiDB version? (Required)

Observed in the current release-8.5 branch.

Branch tip checked:

15cb1cf526f20fae52c5ce09d735cae0aa2eff3c
executor: reduce memTracker.Consume call frequency in StreamAggExec  (#68497) (#68548)
AuthorDate: 2026-05-21T23:15:54+08:00

The relevant code is in:

br/pkg/storage/s3.go

SELECT tidb_version() output is not available from this source-code investigation.