mirror of
https://github.com/s3fs-fuse/s3fs-fuse.git
synced 2026-04-25 13:26:00 +03:00
[GH-ISSUE #2063] CheckBucket fails with restrictive IAM policy and mounting a path #1043
Labels
No labels
bug
bug
dataloss
duplicate
enhancement
feature request
help wanted
invalid
need info
performance
pull-request
question
question
testing
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/s3fs-fuse#1043
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @francisATgwn on GitHub (Nov 22, 2022).
Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/2063
Version of s3fs being used (s3fs --version)
Version of fuse being used (pkg-config --modversion fuse, rpm -qi fuse, dpkg -s fuse)
2.9.9Kernel information (uname -r)
5.15.0-1023-awsGNU/Linux Distribution, if applicable (cat /etc/os-release)
s3fs command line used, if applicable
s3fs syslog messages (grep s3fs /var/log/syslog, journalctl | grep s3fs, or s3fs outputs)
Details about issue
We have a setup that mounts a path under an S3 bucket. The IAM user in question is configured with the minimum necessary permissions, it is restricted to listing and reading objects only under its path prefix in the bucket. It does not have permission to ListBucket on the root of the bucket.
While upgrading from Ubuntu 20.04 to 22.04, s3fs upgraded from 1.86 to 1.90 and experienced a regression in functionality. It worked in 1.86 and fails in 1.90 without any configuration change on our part.
I ran git bisect which found that
d3278f4886is the commit that introduced the regression.Here is the IAM policy in effect on s3fs:
@francisATgwn commented on GitHub (Nov 29, 2022):
To work around this issue until a proper fix is available, we have expanded the IAM permissions by adding the following statement to the policy I included in the issue description. This gives the s3fs user access to run ListBucket on the root of the S3 bucket in question.
However, this was ALSO too restrictive for s3fs. This IAM policy statement does allow listing the root of the S3 bucket:
However, s3fs is still getting a 403, which likely means it is not including the
delimiterandprefixparameters in the request.This statement is now what we're using as the workaround.
@arontsang commented on GitHub (Jan 4, 2023):
+1 We also have this problem. But we cannot use this workaround.
Our company uses shared buckets and partition them to each group.
We can't give everyone root read access, nor can we provision a bucket per group (aws bucket limits).
@ggtakec commented on GitHub (Jan 5, 2023):
@francisATgwn @arontsang
I'm sorry for late to reply and thanks for the details of the problem.
I've created PR #2087 to confirm what the bug was and to make it work as before.
This PR code checks bucket access at first, and if that fails, checks including the directory path.
I think that this code should allow the check to pass as before.
I would appreciate it if you could try it with the code in this PR or please wait for merging.
@ggtakec commented on GitHub (Jan 9, 2023):
#2087 has been merged. Please try it if you can.
This issue will be closed, but if the problem still exists, please reopen it or post a new issue.
@francisATgwn commented on GitHub (Jan 31, 2023):
Confirmed.