GH-50358: [Release] Fix permission issues on Dockerfile on new binary signing image

[raulcd]

Rationale for this change

We updated from bookworm to trixie our binary signing image. When trying to sign the packages it failed with the following error:

Downloading: centos - 100.0% [63/63] 00:01:26 00:00:00  0/s
error: Unable to open sqlite database /var/lib/rpm/rpmdb.sqlite: unable to open database file
error: cannot open Packages index using sqlite - Operation not permitted (1)
error: cannot open Packages database in /var/lib/rpm
error: can't create transaction lock on /var/lib/rpm/.rpm.lock (No such file or directory)
error: /tmp/apache-arrow-binary20260703-49-htq2me.asc: key 1 import failed.

What changes are included in this PR?

Change permissions for /var/lib/rpm inside container.

Are these changes tested?

Yes, I've used that to upload and sign binaries.

Are there any user-facing changes?

No

• GitHub Issue: [Release] Uploading binaries fail with unable to open database file on RPM uploads #50358

[github-actions]

⚠️ GitHub issue #50358 has been automatically assigned in GitHub to PR creator.

[Copilot]

Pull request overview

This PR addresses a release-blocking failure in the Debian trixie-based binary signing image where rpm --import cannot write to the RPM database under /var/lib/rpm, preventing RPM artifact signing/upload during release automation.

Changes:

• Adjusts filesystem permissions in the signing Docker image to allow RPM DB writes during signing.

[kou]

Thanks! But I want to try the following:

diff --git a/dev/release/binary-task.rb b/dev/release/binary-task.rb
index 254ca547fa..ce2bb3f15b 100644
--- a/dev/release/binary-task.rb
+++ b/dev/release/binary-task.rb
@@ -1930,7 +1930,8 @@ APT::FTPArchive::Release::Description "#{apt_repository_description}";
          "--export", gpg_key_id,
          out: gpg_key.path,
          verbose: verbose?)
-      sh("rpm",
+      sh("sudo",
+         "rpm",
          "--import", gpg_key.path,
          out: default_output,
          verbose: verbose?)

Can we try the sudo approach instead of the chmod approach in the next release?