bkietz commented on code in PR #41559:
URL: https://github.com/apache/arrow/pull/41559#discussion_r2031428181
##########
cpp/src/arrow/filesystem/s3fs.cc:
##########
@@ -3031,6 +3034,30 @@ Result<std::string> S3FileSystem::PathFromUri(const
std::string& uri_string) con
internal::AuthorityHandlingBehavior::kPrepend);
}
+Result<std::string> S3FileSystem::MakeUri(std::string path) const {
+ if (path.length() <= 1 || path[0] != '/') {
+ return Status::Invalid("MakeUri requires an absolute, non-root path, got
", path);
+ }
+ ARROW_ASSIGN_OR_RAISE(auto uri, util::UriFromAbsolutePath(path));
+ if (!options().GetAccessKey().empty()) {
+ uri = "s3://" + options().GetAccessKey() + ":" + options().GetSecretKey()
+ "@" +
+ uri.substr("file:///"s.size());
Review Comment:
I can start an ML discussion, but: in `arrow::fs::` URIs are intended to
serve as *complete* specifications of a filesystem. If a filesystem cannot be
constructed without a secret, then either 1. the URI contains that secret or 2.
that filesystem cannot be constructed from a URI
1. In the current design, filesystems simply are secrets, transitively;
anyone who has the URI has access to the filesystem to which it refers.
- This should definitely be documented more rigorously
- it'd probably be a good idea for MakeUri to return a
[SecureString](https://github.com/apache/arrow/pull/46017) too, when that's
merged
3. If URIs-which-are-secrets is unacceptable, we would need to extend the
`FileSystemFactory` interface to support out-of-band secrets somehow.
- For example, we could provide a `SecretRegistry` to which new secrets
may be added like `GetSecretRegistry()->AddSecret({.key = "my-s3-secret-key",
.secret = "sw0rdf1sh"});` then reference those from URIs like
`s3://{my-s3-key}:{my-s3-secret-key}@.../{my-secret-bucket}`
- To me this indirection seems error prone and of the security increment
seems minimal
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
