mirror of
https://github.com/s3fs-fuse/s3fs-fuse.git
synced 2026-04-25 13:26:00 +03:00
[GH-ISSUE #166] s3fs-fuse with ecryptfs? #94
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#94
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 @stevenshiau on GitHub (Apr 10, 2015).
Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/166
Dear maintainer,
I encountered an issue when using ecryptfs with s3fs. Here is how the issue could be reproduced. First put the password file in /tmp/p.txt, and its content is like:
The script "s3fs-ecryptfs.sh" for all the steps:
The results for the above script:
As you can see, the md5sum of "/tmp/ecryptfs_mnt/ok.txt" in the 2nd mounting is different from the 1st one, and it's the same with encrypted file "/home/partimag/test-s3/ok.txt". Therefore you can see ecryptfs failed in decryption.
On the other hand, I tried the nearly same steps, and the only difference is to mount a local partition instead of S3 resource. Here the script "local-ecryptfs.sh" is:
As you can see, the only difference is in the 1st line.
Now the results for the script "local-ecryptfs.sh":
As you can see, the md5sum of "/tmp/ecryptfs_mnt/ok.txt" in the 2nd mounting is the same with the 1st one. This makes sense. Therefore you can see ecryptfs worked in decryption.
Any thought? Did I miss something? Or by nature the 2 file systems conflict with each other?
Thank you very much.
Steven.
@ggtakec commented on GitHub (Apr 18, 2015):
I have not been geting this reason yet.
I tried mounting s3 my bucket on the directory which is mounted by s3fs, but s3fs could get same file.(please see fallowing example.)
example for my test:
I think it seems that nested mounting by s3fs does with no problem.
So this problem has occurred in the case of using eCryptfs.
If you can, please s3fs run with "-d" or "-f" option, it puts s3fs's debugging messages.
We need more informaion to solve this issue.
Thanks in advance for your assistance.
@stevenshiau commented on GitHub (Apr 18, 2015):
Thanks.
I ran s3fs with "-d -f", and the output:
@ggtakec commented on GitHub (Apr 18, 2015):
Thanks for quickly replying.
I saw your s3fs logs, but any error is not in it.(some error in logs are by getting file/directory attributes for finding it, then those are normally message on s3fs)
When my test results, the error in the nest of s3fs (FUSE) did not occur, and the error did not occur in the case when you do not use a s3fs.
I think that In order to find the cause we must look the other way.
I try to find how to test for finding the reason, please you try to think about it.
Thanks in advance for your help.
@stevenshiau commented on GitHub (Apr 18, 2015):
Hi Takeshi,
Thanks. For the tests recently here, I found if I enabled the option "kernel_cache" (s3fs steven-ocs /home/partimag/ -o kernel_cache), it works. However, it only works for small files (~ bytes). When I really put big files (>MB), the "kernel_cache" option does not help.
If I enable the cache dir, yes, it works. i.e.
s3fs steven-ocs /home/partimag/ -o use_cache=/tmp
However, this will have another issue because the /tmp/ will be full eventually and the files uploading eventually fails.
Steven.
@ggtakec commented on GitHub (Apr 18, 2015):
@stevenshiau I'm sorry to know no detail about eCryptfs.
Probably the cause of this issue is because s3fs does not support the extended attributes (xattr).
I will try to support it, please wait by supporting. Please see #169
Regards,
@stevenshiau commented on GitHub (Apr 18, 2015):
Hi Takeshi,
Got it. Thank you very much.
Steven.
@ggtakec commented on GitHub (Apr 20, 2015):
@stevenshiau I created new branch "xattr" which supported extended attributes FUSE api.(posted same comment #169)
Please try to use and test xattr branch codes.
Thanks in advance for your assistance.
@stevenshiau commented on GitHub (Apr 21, 2015):
@ggtakec Thanks. I tested the new branch "xattr", still the results are the same:
The debug info are:
Anything else I need to test?
Thanks for all your efforts.
Steven.
@ggtakec commented on GitHub (Apr 21, 2015):
Hi, Steven
Thanks for replying and testing quickly.
I updated xattr branch codes, please try and check it.
And please see my comment on #169 as same as this issue.
Regards,
@stevenshiau commented on GitHub (Apr 22, 2015):
@ggtakec
Thanks for your updates. I have tested it again. The results are the same.
Anything else I can test?
Thanks for your efforts.
Steven.
@delx commented on GitHub (Apr 27, 2015):
Are you sure that this issue is related to the extended attributes?
@stevenshiau commented on GitHub (Apr 28, 2015):
@delx,
No, I have no idea about that. Ggtakec guessed that. Do you have any idea about the issue?
Thanks.
Steven.
@ggtakec commented on GitHub (Apr 28, 2015):
@delx @stevenshiau
I'm not necessarily sure, but encfs is trying to get the attributes through getxattr(security.capability).
I have not found detailed operation of ecryptfs yet, but I think that a cause is that ecryptfs can not be obtained extended attributes.(Who should write this extended attribute?)
For example, #169 (about encfs) seems like this issue, it puts following log:
I think we need to know how to set these extended attributes for the object which is made by ecryptfs(encfs).
(I don’t know whether this reason is related to the policy settings of the secure OS(SELinux))
I try to study about it, please wait for a while, and if you know about it please let me know.
Thanks in advance for your help.
@ggtakec commented on GitHub (Apr 28, 2015):
Could you run ecryptfs with ecryptfs_xattr option?
@stevenshiau commented on GitHub (Apr 30, 2015):
@ggtakec,
Thanks.
When I mount ecryptfs with ecryptfs_xattr option, I got different error:
Then the error is:
Somehow the option "ecryptfs_xattr" prevents the file creation.
Do you have same error there?
Thanks for your efforts. Appreciate.
Steven.
@ggtakec commented on GitHub (May 10, 2015):
@stevenshiau I'm sorry for replying late.
I tried to do your scenario on ubuntu. I did not get something error about ecryptfs_xattr option yet.
The root of this issue was that md5 is different by the remount.
In the second mount, it is because the file contents through the s3fs + ecryptfs is returned without decoding it.
However, I did not know why not decode the file.
So that, we were trying to run ecryptfs with ecryptfs_xattr and s3fs is changed to add extended attribute interface.
But I found a bug about these xattr interface in s3fs. ecryptfs calls xattr interface through fuse with binary data for extended attributes, but s3fs xattr branch can not handle it now.
Then I try to fix this bug, please wait a moment.
Thanks in advance for your assistance.
@stevenshiau commented on GitHub (May 10, 2015):
@ggtakec,
Got it. Thanks for notifying me that. It's nice to know you made some progress.
Steven.
@ggtakec commented on GitHub (May 17, 2015):
@stevenshiau I’m sorry, still I'm not able to solve this problem.
I fixed that s3fs has been able to receive a binary array as value for extended attribute.
But still this problem which is occurred after remounting is not fixed.
It seems that s3fs could not return the value as "system.posix_acl_default" extended attribute, but this attribute is not set by any calling.
I think this is the cause for this issue.
So I’m examining about POSIX ACL, please wait a while.
Regards,
@stevenshiau commented on GitHub (May 19, 2015):
@ggtakec No problem. I can fully understand that debugging might take a lot of time. I am a very patient user, and really glad that you keep fixing this issue.
Appreciate!
BR,
Steven.
@ggtakec commented on GitHub (Jun 6, 2015):
@stevenshiau
I'm sorry for rplying late.
I fixed xattr branch now, it seems that works good.(after remount)
I was misunderstood, "system.posix_acl_default" does not affect about this issue.
I warry one, that the file size which encoded is not correct at first time before reading it.
After reading the file, the file size is correct.
Note the thing about xattr of s3fs.
s3fs can support extended attributes by put/get "x-amz-meta-xattr" header.
This header is formatted following:
x-amz-meta-xattr: url encoded string({"key":"base64(value)","key":"base64(value)",....})
@ggtakec commented on GitHub (Jun 9, 2015):
At the end of this week, I will try to merge xattr branch to master branch.
If you find a problem, please let me know.
Thanks in advance for your assistance.
@stevenshiau commented on GitHub (Jun 13, 2015):
@ggtakec,
Great!
Sorry for the late response because I have been out of office for a few days. I should be able to do the test again when I back to office next Tuesday.
Steven.
@ggtakec commented on GitHub (Jun 20, 2015):
#199 merged, master branch supports extended attributes.
I closed this issue, if you find a problem, please reopen this issue or post new issue.
Regards,
@stevenshiau commented on GitHub (Jun 20, 2015):
Sorry for the late, and thanks for your updates. However, I tried to compile the master you just merged and did the same test as my 1st post. I still got the same issue. Did you do the similar test with ecryptfs? Does it work there?
Thank you very much.
Steven.
@ggtakec commented on GitHub (Jun 20, 2015):
I’m sorry for forgetting tell you about it.
After remounting encryptfs, encryptfs can not display correct original file size still reading the file contents.
I could not know the reason about this problem.
Maybe then, it encryptfs it may have been due to the fact that use extended attributes(ecryptfs_xattr option used).
But after reading file contents at least once, encryptfs displays correct file size.
Regards,
@stevenshiau commented on GitHub (Jun 27, 2015):
@ggtakec,
Got it. Thanks.
Steven.