fix: do not fall back to anonymous access when --iam is set

[efirs]

One-line guard, backported from geesefs a47ba58. From the backlog triage in #51.

Problem

Startup autodetection sends an unsigned HEAD at the bucket. A 200 back means the bucket answers unauthenticated requests. The code treated that, plus no configured profile and no AWS_ACCESS_KEY_ID in the environment, as evidence the caller wanted anonymous access, and swapped the client onto anonymous credentials:

if len(s.config.Profile) == 0 && os.Getenv("AWS_ACCESS_KEY_ID") == "" {
    s.awsConfig.Credentials = credentials.AnonymousCredentials
    s3Log.Info().Msg("anonymous bucket detected")
}

With --iam neither of those two signals is set, because credentials come from the metadata service instead. So a mount explicitly configured for IAM, pointed at a publicly readable bucket, silently dropped to unauthenticated requests for the rest of its life. Writes then fail, and reads carry no identity, so access control and audit attribution are both wrong. The only trace is an info-level "anonymous bucket detected" line.

Narrow to reach, since it needs --iam together with a bucket that serves an anonymous HEAD, and --no-detect avoids it entirely. But the failure is silent and the fix is one condition.

Change

Require that IAM is not in use before inferring anonymous access.

Also takes the help-text half of the same upstream commit: --no-detect turns off anonymous detection as well as location and signature detection, which the old wording did not mention. That omission is part of why the behaviour is surprising.

Verification

Build, vet and the unit suites pass. No test added: the path needs a live endpoint answering an unsigned HEAD with 200 during backend construction, which the suite has no fixture for. The change is a single conjunct on an existing condition and upstream shipped it the same way.

---

Note

Medium Risk
Touches S3 startup credential selection and IAM vs anonymous behavior; change is a narrow guard but affects authentication for IAM mounts.

Overview
Startup bucket probing can see HTTP 200 on an unsigned HEAD and treat the bucket as anonymously readable, switching the S3 client to anonymous credentials when there is no AWS profile and no AWS_ACCESS_KEY_ID env var.

With --iam, credentials come from instance metadata instead, so those checks are empty even though IAM is intended. Mounts against publicly readable buckets could then stay on anonymous access (failed writes, no identity on reads). This PR adds !s.config.UseIAM to that guard so IAM mounts keep using the IAM signer path.

The --no-detect help text now states that it disables anonymous-access autodetection as well as region and signature detection.

^{Reviewed by Cursor Bugbot for commit 57a7040. Bugbot is set up for automated code reviews on this repo. Configure here.}

[greptile-apps]

Confidence Score: 4/5

[Critical risk] Changes AWS credential fallback logic when IAM is enabled.

The PR appears safe to merge, with a non-blocking regression-test gap in the IAM detection path.

Findings

1.  IAM guard lacks regression coverage ▶

Summary

The PR prevents a successful unsigned bucket HEAD from switching an IAM-configured S3 mount to anonymous credentials and clarifies the --no-detect help text.

• The credential guard addresses the stated identity-loss path.
• The changed branch lacks a focused regression test.

_{Reviews (1) · Last reviewed commit: "fix: do not fall back to anonymous acces..."}

[tigrisdata-argocd-bot]

🎉 This PR is included in version 1.2.4 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀